1 :mod:`threading` --- Higher-level threading interface
2 =====================================================
5 :synopsis: Higher-level threading interface.
8 This module constructs higher-level threading interfaces on top of the lower
9 level :mod:`thread` module.
10 See also the :mod:`mutex` and :mod:`Queue` modules.
12 The :mod:`dummy_threading` module is provided for situations where
13 :mod:`threading` cannot be used because :mod:`thread` is missing.
17 Starting with Python 2.6, this module provides PEP 8 compliant aliases and
18 properties to replace the ``camelCase`` names that were inspired by Java's
19 threading API. This updated API is compatible with that of the
20 :mod:`multiprocessing` module. However, no schedule has been set for the
21 deprecation of the ``camelCase`` names and they remain fully supported in
22 both Python 2.x and 3.x.
26 Starting with Python 2.5, several Thread methods raise :exc:`RuntimeError`
27 instead of :exc:`AssertionError` if called erroneously.
30 This module defines the following functions and objects:
32 .. function:: active_count()
35 Return the number of :class:`Thread` objects currently alive. The returned
36 count is equal to the length of the list returned by :func:`enumerate`.
39 .. function:: Condition()
42 A factory function that returns a new condition variable object. A condition
43 variable allows one or more threads to wait until they are notified by another
47 .. function:: current_thread()
50 Return the current :class:`Thread` object, corresponding to the caller's thread
51 of control. If the caller's thread of control was not created through the
52 :mod:`threading` module, a dummy thread object with limited functionality is
56 .. function:: enumerate()
58 Return a list of all :class:`Thread` objects currently alive. The list
59 includes daemonic threads, dummy thread objects created by
60 :func:`current_thread`, and the main thread. It excludes terminated threads
61 and threads that have not yet been started.
67 A factory function that returns a new event object. An event manages a flag
68 that can be set to true with the :meth:`set` method and reset to false with the
69 :meth:`clear` method. The :meth:`wait` method blocks until the flag is true.
74 A class that represents thread-local data. Thread-local data are data whose
75 values are thread specific. To manage thread-local data, just create an
76 instance of :class:`local` (or a subclass) and store attributes on it::
78 mydata = threading.local()
81 The instance's values will be different for separate threads.
83 For more details and extensive examples, see the documentation string of the
84 :mod:`_threading_local` module.
91 A factory function that returns a new primitive lock object. Once a thread has
92 acquired it, subsequent attempts to acquire it block, until it is released; any
93 thread may release it.
98 A factory function that returns a new reentrant lock object. A reentrant lock
99 must be released by the thread that acquired it. Once a thread has acquired a
100 reentrant lock, the same thread may acquire it again without blocking; the
101 thread must release it once for each time it has acquired it.
104 .. function:: Semaphore([value])
107 A factory function that returns a new semaphore object. A semaphore manages a
108 counter representing the number of :meth:`release` calls minus the number of
109 :meth:`acquire` calls, plus an initial value. The :meth:`acquire` method blocks
110 if necessary until it can return without making the counter negative. If not
111 given, *value* defaults to 1.
114 .. function:: BoundedSemaphore([value])
116 A factory function that returns a new bounded semaphore object. A bounded
117 semaphore checks to make sure its current value doesn't exceed its initial
118 value. If it does, :exc:`ValueError` is raised. In most situations semaphores
119 are used to guard resources with limited capacity. If the semaphore is released
120 too many times it's a sign of a bug. If not given, *value* defaults to 1.
125 A class that represents a thread of control. This class can be safely
126 subclassed in a limited fashion.
131 A thread that executes a function after a specified interval has passed.
134 .. function:: settrace(func)
136 .. index:: single: trace function
138 Set a trace function for all threads started from the :mod:`threading` module.
139 The *func* will be passed to :func:`sys.settrace` for each thread, before its
140 :meth:`run` method is called.
142 .. versionadded:: 2.3
145 .. function:: setprofile(func)
147 .. index:: single: profile function
149 Set a profile function for all threads started from the :mod:`threading` module.
150 The *func* will be passed to :func:`sys.setprofile` for each thread, before its
151 :meth:`run` method is called.
153 .. versionadded:: 2.3
156 .. function:: stack_size([size])
158 Return the thread stack size used when creating new threads. The optional
159 *size* argument specifies the stack size to be used for subsequently created
160 threads, and must be 0 (use platform or configured default) or a positive
161 integer value of at least 32,768 (32kB). If changing the thread stack size is
162 unsupported, a :exc:`ThreadError` is raised. If the specified stack size is
163 invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32kB
164 is currently the minimum supported stack size value to guarantee sufficient
165 stack space for the interpreter itself. Note that some platforms may have
166 particular restrictions on values for the stack size, such as requiring a
167 minimum stack size > 32kB or requiring allocation in multiples of the system
168 memory page size - platform documentation should be referred to for more
169 information (4kB pages are common; using multiples of 4096 for the stack size is
170 the suggested approach in the absence of more specific information).
171 Availability: Windows, systems with POSIX threads.
173 .. versionadded:: 2.5
175 Detailed interfaces for the objects are documented below.
177 The design of this module is loosely based on Java's threading model. However,
178 where Java makes locks and condition variables basic behavior of every object,
179 they are separate objects in Python. Python's :class:`Thread` class supports a
180 subset of the behavior of Java's Thread class; currently, there are no
181 priorities, no thread groups, and threads cannot be destroyed, stopped,
182 suspended, resumed, or interrupted. The static methods of Java's Thread class,
183 when implemented, are mapped to module-level functions.
185 All of the methods described below are executed atomically.
193 This class represents an activity that is run in a separate thread of control.
194 There are two ways to specify the activity: by passing a callable object to the
195 constructor, or by overriding the :meth:`run` method in a subclass. No other
196 methods (except for the constructor) should be overridden in a subclass. In
197 other words, *only* override the :meth:`__init__` and :meth:`run` methods of
200 Once a thread object is created, its activity must be started by calling the
201 thread's :meth:`start` method. This invokes the :meth:`run` method in a
202 separate thread of control.
204 Once the thread's activity is started, the thread is considered 'alive'. It
205 stops being alive when its :meth:`run` method terminates -- either normally, or
206 by raising an unhandled exception. The :meth:`is_alive` method tests whether the
209 Other threads can call a thread's :meth:`join` method. This blocks the calling
210 thread until the thread whose :meth:`join` method is called is terminated.
212 A thread has a name. The name can be passed to the constructor, and read or
213 changed through the :attr:`name` attribute.
215 A thread can be flagged as a "daemon thread". The significance of this flag is
216 that the entire Python program exits when only daemon threads are left. The
217 initial value is inherited from the creating thread. The flag can be set
218 through the :attr:`daemon` property.
220 There is a "main thread" object; this corresponds to the initial thread of
221 control in the Python program. It is not a daemon thread.
223 There is the possibility that "dummy thread objects" are created. These are
224 thread objects corresponding to "alien threads", which are threads of control
225 started outside the threading module, such as directly from C code. Dummy
226 thread objects have limited functionality; they are always considered alive and
227 daemonic, and cannot be :meth:`join`\ ed. They are never deleted, since it is
228 impossible to detect the termination of alien threads.
231 .. class:: Thread(group=None, target=None, name=None, args=(), kwargs={})
233 This constructor should always be called with keyword arguments. Arguments are:
235 *group* should be ``None``; reserved for future extension when a
236 :class:`ThreadGroup` class is implemented.
238 *target* is the callable object to be invoked by the :meth:`run` method.
239 Defaults to ``None``, meaning nothing is called.
241 *name* is the thread name. By default, a unique name is constructed of the form
242 "Thread-*N*" where *N* is a small decimal number.
244 *args* is the argument tuple for the target invocation. Defaults to ``()``.
246 *kwargs* is a dictionary of keyword arguments for the target invocation.
249 If the subclass overrides the constructor, it must make sure to invoke the base
250 class constructor (``Thread.__init__()``) before doing anything else to the
254 .. method:: Thread.start()
256 Start the thread's activity.
258 It must be called at most once per thread object. It arranges for the object's
259 :meth:`run` method to be invoked in a separate thread of control.
261 This method will raise a :exc:`RuntimeException` if called more than once on the
265 .. method:: Thread.run()
267 Method representing the thread's activity.
269 You may override this method in a subclass. The standard :meth:`run` method
270 invokes the callable object passed to the object's constructor as the *target*
271 argument, if any, with sequential and keyword arguments taken from the *args*
272 and *kwargs* arguments, respectively.
275 .. method:: Thread.join([timeout])
277 Wait until the thread terminates. This blocks the calling thread until the
278 thread whose :meth:`join` method is called terminates -- either normally or
279 through an unhandled exception -- or until the optional timeout occurs.
281 When the *timeout* argument is present and not ``None``, it should be a floating
282 point number specifying a timeout for the operation in seconds (or fractions
283 thereof). As :meth:`join` always returns ``None``, you must call :meth:`isAlive`
284 after :meth:`join` to decide whether a timeout happened -- if the thread is
285 still alive, the :meth:`join` call timed out.
287 When the *timeout* argument is not present or ``None``, the operation will block
288 until the thread terminates.
290 A thread can be :meth:`join`\ ed many times.
292 :meth:`join` raises a :exc:`RuntimeError` if an attempt is made to join
293 the current thread as that would cause a deadlock. It is also an error to
294 :meth:`join` a thread before it has been started and attempts to do so
295 raises the same exception.
298 .. method:: Thread.getName()
301 Old API for :attr:`~Thread.name`.
304 .. attribute:: Thread.name
306 A string used for identification purposes only. It has no semantics.
307 Multiple threads may be given the same name. The initial name is set by the
311 .. attribute:: Thread.ident
313 The 'thread identifier' of this thread or ``None`` if the thread has not been
314 started. This is a nonzero integer. See the :func:`thread.get_ident()`
315 function. Thread identifiers may be recycled when a thread exits and another
316 thread is created. The identifier is available even after the thread has
319 .. versionadded:: 2.6
322 .. method:: Thread.is_alive()
325 Return whether the thread is alive.
327 Roughly, a thread is alive from the moment the :meth:`start` method returns
328 until its :meth:`run` method terminates. The module function :func:`enumerate`
329 returns a list of all alive threads.
332 .. method:: Thread.isDaemon()
335 Old API for :attr:`~Thread.daemon`.
338 .. attribute:: Thread.daemon
340 A boolean value indicating whether this thread is a daemon thread (True) or
341 not (False). This must be set before :meth:`start` is called, otherwise
342 :exc:`RuntimeError` is raised. Its initial value is inherited from the
343 creating thread; the main thread is not a daemon thread and therefore all
344 threads created in the main thread default to :attr:`daemon` = ``False``.
346 The entire Python program exits when no alive non-daemon threads are left.
354 A primitive lock is a synchronization primitive that is not owned by a
355 particular thread when locked. In Python, it is currently the lowest level
356 synchronization primitive available, implemented directly by the :mod:`thread`
359 A primitive lock is in one of two states, "locked" or "unlocked". It is created
360 in the unlocked state. It has two basic methods, :meth:`acquire` and
361 :meth:`release`. When the state is unlocked, :meth:`acquire` changes the state
362 to locked and returns immediately. When the state is locked, :meth:`acquire`
363 blocks until a call to :meth:`release` in another thread changes it to unlocked,
364 then the :meth:`acquire` call resets it to locked and returns. The
365 :meth:`release` method should only be called in the locked state; it changes the
366 state to unlocked and returns immediately. If an attempt is made to release an
367 unlocked lock, a :exc:`RuntimeError` will be raised.
369 When more than one thread is blocked in :meth:`acquire` waiting for the state to
370 turn to unlocked, only one thread proceeds when a :meth:`release` call resets
371 the state to unlocked; which one of the waiting threads proceeds is not defined,
372 and may vary across implementations.
374 All methods are executed atomically.
377 .. method:: Lock.acquire([blocking=1])
379 Acquire a lock, blocking or non-blocking.
381 When invoked without arguments, block until the lock is unlocked, then set it to
382 locked, and return true.
384 When invoked with the *blocking* argument set to true, do the same thing as when
385 called without arguments, and return true.
387 When invoked with the *blocking* argument set to false, do not block. If a call
388 without an argument would block, return false immediately; otherwise, do the
389 same thing as when called without arguments, and return true.
392 .. method:: Lock.release()
396 When the lock is locked, reset it to unlocked, and return. If any other threads
397 are blocked waiting for the lock to become unlocked, allow exactly one of them
400 Do not call this method when the lock is unlocked.
402 There is no return value.
410 A reentrant lock is a synchronization primitive that may be acquired multiple
411 times by the same thread. Internally, it uses the concepts of "owning thread"
412 and "recursion level" in addition to the locked/unlocked state used by primitive
413 locks. In the locked state, some thread owns the lock; in the unlocked state,
416 To lock the lock, a thread calls its :meth:`acquire` method; this returns once
417 the thread owns the lock. To unlock the lock, a thread calls its
418 :meth:`release` method. :meth:`acquire`/:meth:`release` call pairs may be
419 nested; only the final :meth:`release` (the :meth:`release` of the outermost
420 pair) resets the lock to unlocked and allows another thread blocked in
421 :meth:`acquire` to proceed.
424 .. method:: RLock.acquire([blocking=1])
426 Acquire a lock, blocking or non-blocking.
428 When invoked without arguments: if this thread already owns the lock, increment
429 the recursion level by one, and return immediately. Otherwise, if another
430 thread owns the lock, block until the lock is unlocked. Once the lock is
431 unlocked (not owned by any thread), then grab ownership, set the recursion level
432 to one, and return. If more than one thread is blocked waiting until the lock
433 is unlocked, only one at a time will be able to grab ownership of the lock.
434 There is no return value in this case.
436 When invoked with the *blocking* argument set to true, do the same thing as when
437 called without arguments, and return true.
439 When invoked with the *blocking* argument set to false, do not block. If a call
440 without an argument would block, return false immediately; otherwise, do the
441 same thing as when called without arguments, and return true.
444 .. method:: RLock.release()
446 Release a lock, decrementing the recursion level. If after the decrement it is
447 zero, reset the lock to unlocked (not owned by any thread), and if any other
448 threads are blocked waiting for the lock to become unlocked, allow exactly one
449 of them to proceed. If after the decrement the recursion level is still
450 nonzero, the lock remains locked and owned by the calling thread.
452 Only call this method when the calling thread owns the lock. A
453 :exc:`RuntimeError` is raised if this method is called when the lock is
456 There is no return value.
459 .. _condition-objects:
464 A condition variable is always associated with some kind of lock; this can be
465 passed in or one will be created by default. (Passing one in is useful when
466 several condition variables must share the same lock.)
468 A condition variable has :meth:`acquire` and :meth:`release` methods that call
469 the corresponding methods of the associated lock. It also has a :meth:`wait`
470 method, and :meth:`notify` and :meth:`notifyAll` methods. These three must only
471 be called when the calling thread has acquired the lock, otherwise a
472 :exc:`RuntimeError` is raised.
474 The :meth:`wait` method releases the lock, and then blocks until it is awakened
475 by a :meth:`notify` or :meth:`notifyAll` call for the same condition variable in
476 another thread. Once awakened, it re-acquires the lock and returns. It is also
477 possible to specify a timeout.
479 The :meth:`notify` method wakes up one of the threads waiting for the condition
480 variable, if any are waiting. The :meth:`notifyAll` method wakes up all threads
481 waiting for the condition variable.
483 Note: the :meth:`notify` and :meth:`notifyAll` methods don't release the lock;
484 this means that the thread or threads awakened will not return from their
485 :meth:`wait` call immediately, but only when the thread that called
486 :meth:`notify` or :meth:`notifyAll` finally relinquishes ownership of the lock.
488 Tip: the typical programming style using condition variables uses the lock to
489 synchronize access to some shared state; threads that are interested in a
490 particular change of state call :meth:`wait` repeatedly until they see the
491 desired state, while threads that modify the state call :meth:`notify` or
492 :meth:`notifyAll` when they change the state in such a way that it could
493 possibly be a desired state for one of the waiters. For example, the following
494 code is a generic producer-consumer situation with unlimited buffer capacity::
498 while not an_item_is_available():
500 get_an_available_item()
505 make_an_item_available()
509 To choose between :meth:`notify` and :meth:`notifyAll`, consider whether one
510 state change can be interesting for only one or several waiting threads. E.g.
511 in a typical producer-consumer situation, adding one item to the buffer only
512 needs to wake up one consumer thread.
515 .. class:: Condition([lock])
517 If the *lock* argument is given and not ``None``, it must be a :class:`Lock` or
518 :class:`RLock` object, and it is used as the underlying lock. Otherwise, a new
519 :class:`RLock` object is created and used as the underlying lock.
522 .. method:: Condition.acquire(*args)
524 Acquire the underlying lock. This method calls the corresponding method on the
525 underlying lock; the return value is whatever that method returns.
528 .. method:: Condition.release()
530 Release the underlying lock. This method calls the corresponding method on the
531 underlying lock; there is no return value.
534 .. method:: Condition.wait([timeout])
536 Wait until notified or until a timeout occurs. If the calling thread has not
537 acquired the lock when this method is called, a :exc:`RuntimeError` is raised.
539 This method releases the underlying lock, and then blocks until it is awakened
540 by a :meth:`notify` or :meth:`notifyAll` call for the same condition variable in
541 another thread, or until the optional timeout occurs. Once awakened or timed
542 out, it re-acquires the lock and returns.
544 When the *timeout* argument is present and not ``None``, it should be a floating
545 point number specifying a timeout for the operation in seconds (or fractions
548 When the underlying lock is an :class:`RLock`, it is not released using its
549 :meth:`release` method, since this may not actually unlock the lock when it was
550 acquired multiple times recursively. Instead, an internal interface of the
551 :class:`RLock` class is used, which really unlocks it even when it has been
552 recursively acquired several times. Another internal interface is then used to
553 restore the recursion level when the lock is reacquired.
556 .. method:: Condition.notify()
558 Wake up a thread waiting on this condition, if any. If the calling thread
559 has not acquired the lock when this method is called, a :exc:`RuntimeError`
562 This method wakes up one of the threads waiting for the condition variable,
563 if any are waiting; it is a no-op if no threads are waiting.
565 The current implementation wakes up exactly one thread, if any are waiting.
566 However, it's not safe to rely on this behavior. A future, optimized
567 implementation may occasionally wake up more than one thread.
569 Note: the awakened thread does not actually return from its :meth:`wait` call
570 until it can reacquire the lock. Since :meth:`notify` does not release the
571 lock, its caller should.
574 .. method:: Condition.notify_all()
575 Condition.notifyAll()
577 Wake up all threads waiting on this condition. This method acts like
578 :meth:`notify`, but wakes up all waiting threads instead of one. If the calling
579 thread has not acquired the lock when this method is called, a
580 :exc:`RuntimeError` is raised.
583 .. _semaphore-objects:
588 This is one of the oldest synchronization primitives in the history of computer
589 science, invented by the early Dutch computer scientist Edsger W. Dijkstra (he
590 used :meth:`P` and :meth:`V` instead of :meth:`acquire` and :meth:`release`).
592 A semaphore manages an internal counter which is decremented by each
593 :meth:`acquire` call and incremented by each :meth:`release` call. The counter
594 can never go below zero; when :meth:`acquire` finds that it is zero, it blocks,
595 waiting until some other thread calls :meth:`release`.
598 .. class:: Semaphore([value])
600 The optional argument gives the initial *value* for the internal counter; it
601 defaults to ``1``. If the *value* given is less than 0, :exc:`ValueError` is
605 .. method:: Semaphore.acquire([blocking])
609 When invoked without arguments: if the internal counter is larger than zero on
610 entry, decrement it by one and return immediately. If it is zero on entry,
611 block, waiting until some other thread has called :meth:`release` to make it
612 larger than zero. This is done with proper interlocking so that if multiple
613 :meth:`acquire` calls are blocked, :meth:`release` will wake exactly one of them
614 up. The implementation may pick one at random, so the order in which blocked
615 threads are awakened should not be relied on. There is no return value in this
618 When invoked with *blocking* set to true, do the same thing as when called
619 without arguments, and return true.
621 When invoked with *blocking* set to false, do not block. If a call without an
622 argument would block, return false immediately; otherwise, do the same thing as
623 when called without arguments, and return true.
626 .. method:: Semaphore.release()
628 Release a semaphore, incrementing the internal counter by one. When it was zero
629 on entry and another thread is waiting for it to become larger than zero again,
633 .. _semaphore-examples:
635 :class:`Semaphore` Example
636 ^^^^^^^^^^^^^^^^^^^^^^^^^^
638 Semaphores are often used to guard resources with limited capacity, for example,
639 a database server. In any situation where the size of the resource size is
640 fixed, you should use a bounded semaphore. Before spawning any worker threads,
641 your main thread would initialize the semaphore::
645 pool_sema = BoundedSemaphore(value=maxconnections)
647 Once spawned, worker threads call the semaphore's acquire and release methods
648 when they need to connect to the server::
652 ... use connection ...
656 The use of a bounded semaphore reduces the chance that a programming error which
657 causes the semaphore to be released more than it's acquired will go undetected.
665 This is one of the simplest mechanisms for communication between threads: one
666 thread signals an event and other threads wait for it.
668 An event object manages an internal flag that can be set to true with the
669 :meth:`set` method and reset to false with the :meth:`clear` method. The
670 :meth:`wait` method blocks until the flag is true.
675 The internal flag is initially false.
678 .. method:: Event.is_set()
681 Return true if and only if the internal flag is true.
684 .. method:: Event.set()
686 Set the internal flag to true. All threads waiting for it to become true are
687 awakened. Threads that call :meth:`wait` once the flag is true will not block at
691 .. method:: Event.clear()
693 Reset the internal flag to false. Subsequently, threads calling :meth:`wait`
694 will block until :meth:`set` is called to set the internal flag to true again.
697 .. method:: Event.wait([timeout])
699 Block until the internal flag is true. If the internal flag is true on entry,
700 return immediately. Otherwise, block until another thread calls :meth:`set`
701 to set the flag to true, or until the optional timeout occurs.
703 When the timeout argument is present and not ``None``, it should be a floating
704 point number specifying a timeout for the operation in seconds (or fractions
707 This method returns the internal flag on exit, so it will always return
708 ``True`` except if a timeout is given and the operation times out.
710 .. versionchanged:: 2.7
711 Previously, the method always returned ``None``.
719 This class represents an action that should be run only after a certain amount
720 of time has passed --- a timer. :class:`Timer` is a subclass of :class:`Thread`
721 and as such also functions as an example of creating custom threads.
723 Timers are started, as with threads, by calling their :meth:`start` method. The
724 timer can be stopped (before its action has begun) by calling the :meth:`cancel`
725 method. The interval the timer will wait before executing its action may not be
726 exactly the same as the interval specified by the user.
733 t = Timer(30.0, hello)
734 t.start() # after 30 seconds, "hello, world" will be printed
737 .. class:: Timer(interval, function, args=[], kwargs={})
739 Create a timer that will run *function* with arguments *args* and keyword
740 arguments *kwargs*, after *interval* seconds have passed.
743 .. method:: Timer.cancel()
745 Stop the timer, and cancel the execution of the timer's action. This will only
746 work if the timer is still in its waiting stage.
751 Using locks, conditions, and semaphores in the :keyword:`with` statement
752 ------------------------------------------------------------------------
754 All of the objects provided by this module that have :meth:`acquire` and
755 :meth:`release` methods can be used as context managers for a :keyword:`with`
756 statement. The :meth:`acquire` method will be called when the block is entered,
757 and :meth:`release` will be called when the block is exited.
759 Currently, :class:`Lock`, :class:`RLock`, :class:`Condition`,
760 :class:`Semaphore`, and :class:`BoundedSemaphore` objects may be used as
761 :keyword:`with` statement context managers. For example::
765 some_rlock = threading.RLock()
768 print "some_rlock is locked while this executes"
771 .. _threaded-imports:
773 Importing in threaded code
774 --------------------------
776 While the import machinery is thread safe, there are two key
777 restrictions on threaded imports due to inherent limitations in the way
778 that thread safety is provided:
780 * Firstly, other than in the main module, an import should not have the
781 side effect of spawning a new thread and then waiting for that thread in
782 any way. Failing to abide by this restriction can lead to a deadlock if
783 the spawned thread directly or indirectly attempts to import a module.
784 * Secondly, all import attempts must be completed before the interpreter
785 starts shutting itself down. This can be most easily achieved by only
786 performing imports from non-daemon threads created through the threading
787 module. Daemon threads and threads created directly with the thread
788 module will require some other form of synchronization to ensure they do
789 not attempt imports after system shutdown has commenced. Failure to
790 abide by this restriction will lead to intermittent exceptions and
791 crashes during interpreter shutdown (as the late imports attempt to
792 access machinery which is no longer in a valid state).