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:`~Event.set` method and reset to false
69 with the :meth:`clear` method. The :meth:`wait` method blocks until the flag
75 A class that represents thread-local data. Thread-local data are data whose
76 values are thread specific. To manage thread-local data, just create an
77 instance of :class:`local` (or a subclass) and store attributes on it::
79 mydata = threading.local()
82 The instance's values will be different for separate threads.
84 For more details and extensive examples, see the documentation string of the
85 :mod:`_threading_local` module.
92 A factory function that returns a new primitive lock object. Once a thread has
93 acquired it, subsequent attempts to acquire it block, until it is released; any
94 thread may release it.
99 A factory function that returns a new reentrant lock object. A reentrant lock
100 must be released by the thread that acquired it. Once a thread has acquired a
101 reentrant lock, the same thread may acquire it again without blocking; the
102 thread must release it once for each time it has acquired it.
105 .. function:: Semaphore([value])
108 A factory function that returns a new semaphore object. A semaphore manages a
109 counter representing the number of :meth:`release` calls minus the number of
110 :meth:`acquire` calls, plus an initial value. The :meth:`acquire` method blocks
111 if necessary until it can return without making the counter negative. If not
112 given, *value* defaults to 1.
115 .. function:: BoundedSemaphore([value])
117 A factory function that returns a new bounded semaphore object. A bounded
118 semaphore checks to make sure its current value doesn't exceed its initial
119 value. If it does, :exc:`ValueError` is raised. In most situations semaphores
120 are used to guard resources with limited capacity. If the semaphore is released
121 too many times it's a sign of a bug. If not given, *value* defaults to 1.
126 A class that represents a thread of control. This class can be safely
127 subclassed in a limited fashion.
132 A thread that executes a function after a specified interval has passed.
135 .. function:: settrace(func)
137 .. index:: single: trace function
139 Set a trace function for all threads started from the :mod:`threading` module.
140 The *func* will be passed to :func:`sys.settrace` for each thread, before its
141 :meth:`run` method is called.
143 .. versionadded:: 2.3
146 .. function:: setprofile(func)
148 .. index:: single: profile function
150 Set a profile function for all threads started from the :mod:`threading` module.
151 The *func* will be passed to :func:`sys.setprofile` for each thread, before its
152 :meth:`run` method is called.
154 .. versionadded:: 2.3
157 .. function:: stack_size([size])
159 Return the thread stack size used when creating new threads. The optional
160 *size* argument specifies the stack size to be used for subsequently created
161 threads, and must be 0 (use platform or configured default) or a positive
162 integer value of at least 32,768 (32kB). If changing the thread stack size is
163 unsupported, a :exc:`ThreadError` is raised. If the specified stack size is
164 invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32kB
165 is currently the minimum supported stack size value to guarantee sufficient
166 stack space for the interpreter itself. Note that some platforms may have
167 particular restrictions on values for the stack size, such as requiring a
168 minimum stack size > 32kB or requiring allocation in multiples of the system
169 memory page size - platform documentation should be referred to for more
170 information (4kB pages are common; using multiples of 4096 for the stack size is
171 the suggested approach in the absence of more specific information).
172 Availability: Windows, systems with POSIX threads.
174 .. versionadded:: 2.5
176 Detailed interfaces for the objects are documented below.
178 The design of this module is loosely based on Java's threading model. However,
179 where Java makes locks and condition variables basic behavior of every object,
180 they are separate objects in Python. Python's :class:`Thread` class supports a
181 subset of the behavior of Java's Thread class; currently, there are no
182 priorities, no thread groups, and threads cannot be destroyed, stopped,
183 suspended, resumed, or interrupted. The static methods of Java's Thread class,
184 when implemented, are mapped to module-level functions.
186 All of the methods described below are executed atomically.
194 This class represents an activity that is run in a separate thread of control.
195 There are two ways to specify the activity: by passing a callable object to the
196 constructor, or by overriding the :meth:`run` method in a subclass. No other
197 methods (except for the constructor) should be overridden in a subclass. In
198 other words, *only* override the :meth:`__init__` and :meth:`run` methods of
201 Once a thread object is created, its activity must be started by calling the
202 thread's :meth:`start` method. This invokes the :meth:`run` method in a
203 separate thread of control.
205 Once the thread's activity is started, the thread is considered 'alive'. It
206 stops being alive when its :meth:`run` method terminates -- either normally, or
207 by raising an unhandled exception. The :meth:`is_alive` method tests whether the
210 Other threads can call a thread's :meth:`join` method. This blocks the calling
211 thread until the thread whose :meth:`join` method is called is terminated.
213 A thread has a name. The name can be passed to the constructor, and read or
214 changed through the :attr:`name` attribute.
216 A thread can be flagged as a "daemon thread". The significance of this flag is
217 that the entire Python program exits when only daemon threads are left. The
218 initial value is inherited from the creating thread. The flag can be set
219 through the :attr:`daemon` property.
221 There is a "main thread" object; this corresponds to the initial thread of
222 control in the Python program. It is not a daemon thread.
224 There is the possibility that "dummy thread objects" are created. These are
225 thread objects corresponding to "alien threads", which are threads of control
226 started outside the threading module, such as directly from C code. Dummy
227 thread objects have limited functionality; they are always considered alive and
228 daemonic, and cannot be :meth:`join`\ ed. They are never deleted, since it is
229 impossible to detect the termination of alien threads.
232 .. class:: Thread(group=None, target=None, name=None, args=(), kwargs={})
234 This constructor should always be called with keyword arguments. Arguments
237 *group* should be ``None``; reserved for future extension when a
238 :class:`ThreadGroup` class is implemented.
240 *target* is the callable object to be invoked by the :meth:`run` method.
241 Defaults to ``None``, meaning nothing is called.
243 *name* is the thread name. By default, a unique name is constructed of the
244 form "Thread-*N*" where *N* is a small decimal number.
246 *args* is the argument tuple for the target invocation. Defaults to ``()``.
248 *kwargs* is a dictionary of keyword arguments for the target invocation.
251 If the subclass overrides the constructor, it must make sure to invoke the
252 base class constructor (``Thread.__init__()``) before doing anything else to
257 Start the thread's activity.
259 It must be called at most once per thread object. It arranges for the
260 object's :meth:`run` method to be invoked in a separate thread of control.
262 This method will raise a :exc:`RuntimeException` if called more than once
263 on the same thread object.
267 Method representing the thread's activity.
269 You may override this method in a subclass. The standard :meth:`run`
270 method invokes the callable object passed to the object's constructor as
271 the *target* argument, if any, with sequential and keyword arguments taken
272 from the *args* and *kwargs* arguments, respectively.
274 .. method:: join([timeout])
276 Wait until the thread terminates. This blocks the calling thread until the
277 thread whose :meth:`join` method is called terminates -- either normally
278 or through an unhandled exception -- or until the optional timeout occurs.
280 When the *timeout* argument is present and not ``None``, it should be a
281 floating point number specifying a timeout for the operation in seconds
282 (or fractions thereof). As :meth:`join` always returns ``None``, you must
283 call :meth:`isAlive` after :meth:`join` to decide whether a timeout
284 happened -- if the thread is still alive, the :meth:`join` call timed out.
286 When the *timeout* argument is not present or ``None``, the operation will
287 block until the thread terminates.
289 A thread can be :meth:`join`\ ed many times.
291 :meth:`join` raises a :exc:`RuntimeError` if an attempt is made to join
292 the current thread as that would cause a deadlock. It is also an error to
293 :meth:`join` a thread before it has been started and attempts to do so
294 raises the same exception.
296 .. method:: getName()
299 Old API for :attr:`~Thread.name`.
303 A string used for identification purposes only. It has no semantics.
304 Multiple threads may be given the same name. The initial name is set by
309 The 'thread identifier' of this thread or ``None`` if the thread has not
310 been started. This is a nonzero integer. See the
311 :func:`thread.get_ident()` function. Thread identifiers may be recycled
312 when a thread exits and another thread is created. The identifier is
313 available even after the thread has exited.
315 .. versionadded:: 2.6
317 .. method:: is_alive()
320 Return whether the thread is alive.
322 Roughly, a thread is alive from the moment the :meth:`start` method
323 returns until its :meth:`run` method terminates. The module function
324 :func:`enumerate` returns a list of all alive threads.
326 .. method:: isDaemon()
329 Old API for :attr:`~Thread.daemon`.
331 .. attribute:: daemon
333 A boolean value indicating whether this thread is a daemon thread (True)
334 or not (False). This must be set before :meth:`start` is called,
335 otherwise :exc:`RuntimeError` is raised. Its initial value is inherited
336 from the creating thread; the main thread is not a daemon thread and
337 therefore all threads created in the main thread default to :attr:`daemon`
340 The entire Python program exits when no alive non-daemon threads are left.
348 A primitive lock is a synchronization primitive that is not owned by a
349 particular thread when locked. In Python, it is currently the lowest level
350 synchronization primitive available, implemented directly by the :mod:`thread`
353 A primitive lock is in one of two states, "locked" or "unlocked". It is created
354 in the unlocked state. It has two basic methods, :meth:`acquire` and
355 :meth:`release`. When the state is unlocked, :meth:`acquire` changes the state
356 to locked and returns immediately. When the state is locked, :meth:`acquire`
357 blocks until a call to :meth:`release` in another thread changes it to unlocked,
358 then the :meth:`acquire` call resets it to locked and returns. The
359 :meth:`release` method should only be called in the locked state; it changes the
360 state to unlocked and returns immediately. If an attempt is made to release an
361 unlocked lock, a :exc:`RuntimeError` will be raised.
363 When more than one thread is blocked in :meth:`acquire` waiting for the state to
364 turn to unlocked, only one thread proceeds when a :meth:`release` call resets
365 the state to unlocked; which one of the waiting threads proceeds is not defined,
366 and may vary across implementations.
368 All methods are executed atomically.
371 .. method:: Lock.acquire([blocking=1])
373 Acquire a lock, blocking or non-blocking.
375 When invoked without arguments, block until the lock is unlocked, then set it to
376 locked, and return true.
378 When invoked with the *blocking* argument set to true, do the same thing as when
379 called without arguments, and return true.
381 When invoked with the *blocking* argument set to false, do not block. If a call
382 without an argument would block, return false immediately; otherwise, do the
383 same thing as when called without arguments, and return true.
386 .. method:: Lock.release()
390 When the lock is locked, reset it to unlocked, and return. If any other threads
391 are blocked waiting for the lock to become unlocked, allow exactly one of them
394 Do not call this method when the lock is unlocked.
396 There is no return value.
404 A reentrant lock is a synchronization primitive that may be acquired multiple
405 times by the same thread. Internally, it uses the concepts of "owning thread"
406 and "recursion level" in addition to the locked/unlocked state used by primitive
407 locks. In the locked state, some thread owns the lock; in the unlocked state,
410 To lock the lock, a thread calls its :meth:`acquire` method; this returns once
411 the thread owns the lock. To unlock the lock, a thread calls its
412 :meth:`release` method. :meth:`acquire`/:meth:`release` call pairs may be
413 nested; only the final :meth:`release` (the :meth:`release` of the outermost
414 pair) resets the lock to unlocked and allows another thread blocked in
415 :meth:`acquire` to proceed.
418 .. method:: RLock.acquire([blocking=1])
420 Acquire a lock, blocking or non-blocking.
422 When invoked without arguments: if this thread already owns the lock, increment
423 the recursion level by one, and return immediately. Otherwise, if another
424 thread owns the lock, block until the lock is unlocked. Once the lock is
425 unlocked (not owned by any thread), then grab ownership, set the recursion level
426 to one, and return. If more than one thread is blocked waiting until the lock
427 is unlocked, only one at a time will be able to grab ownership of the lock.
428 There is no return value in this case.
430 When invoked with the *blocking* argument set to true, do the same thing as when
431 called without arguments, and return true.
433 When invoked with the *blocking* argument set to false, do not block. If a call
434 without an argument would block, return false immediately; otherwise, do the
435 same thing as when called without arguments, and return true.
438 .. method:: RLock.release()
440 Release a lock, decrementing the recursion level. If after the decrement it is
441 zero, reset the lock to unlocked (not owned by any thread), and if any other
442 threads are blocked waiting for the lock to become unlocked, allow exactly one
443 of them to proceed. If after the decrement the recursion level is still
444 nonzero, the lock remains locked and owned by the calling thread.
446 Only call this method when the calling thread owns the lock. A
447 :exc:`RuntimeError` is raised if this method is called when the lock is
450 There is no return value.
453 .. _condition-objects:
458 A condition variable is always associated with some kind of lock; this can be
459 passed in or one will be created by default. (Passing one in is useful when
460 several condition variables must share the same lock.)
462 A condition variable has :meth:`acquire` and :meth:`release` methods that call
463 the corresponding methods of the associated lock. It also has a :meth:`wait`
464 method, and :meth:`notify` and :meth:`notifyAll` methods. These three must only
465 be called when the calling thread has acquired the lock, otherwise a
466 :exc:`RuntimeError` is raised.
468 The :meth:`wait` method releases the lock, and then blocks until it is awakened
469 by a :meth:`notify` or :meth:`notifyAll` call for the same condition variable in
470 another thread. Once awakened, it re-acquires the lock and returns. It is also
471 possible to specify a timeout.
473 The :meth:`notify` method wakes up one of the threads waiting for the condition
474 variable, if any are waiting. The :meth:`notifyAll` method wakes up all threads
475 waiting for the condition variable.
477 Note: the :meth:`notify` and :meth:`notifyAll` methods don't release the lock;
478 this means that the thread or threads awakened will not return from their
479 :meth:`wait` call immediately, but only when the thread that called
480 :meth:`notify` or :meth:`notifyAll` finally relinquishes ownership of the lock.
482 Tip: the typical programming style using condition variables uses the lock to
483 synchronize access to some shared state; threads that are interested in a
484 particular change of state call :meth:`wait` repeatedly until they see the
485 desired state, while threads that modify the state call :meth:`notify` or
486 :meth:`notifyAll` when they change the state in such a way that it could
487 possibly be a desired state for one of the waiters. For example, the following
488 code is a generic producer-consumer situation with unlimited buffer capacity::
492 while not an_item_is_available():
494 get_an_available_item()
499 make_an_item_available()
503 To choose between :meth:`notify` and :meth:`notifyAll`, consider whether one
504 state change can be interesting for only one or several waiting threads. E.g.
505 in a typical producer-consumer situation, adding one item to the buffer only
506 needs to wake up one consumer thread.
509 .. class:: Condition([lock])
511 If the *lock* argument is given and not ``None``, it must be a :class:`Lock`
512 or :class:`RLock` object, and it is used as the underlying lock. Otherwise,
513 a new :class:`RLock` object is created and used as the underlying lock.
515 .. method:: acquire(*args)
517 Acquire the underlying lock. This method calls the corresponding method on
518 the underlying lock; the return value is whatever that method returns.
520 .. method:: release()
522 Release the underlying lock. This method calls the corresponding method on
523 the underlying lock; there is no return value.
525 .. method:: wait([timeout])
527 Wait until notified or until a timeout occurs. If the calling thread has not
528 acquired the lock when this method is called, a :exc:`RuntimeError` is raised.
530 This method releases the underlying lock, and then blocks until it is
531 awakened by a :meth:`notify` or :meth:`notifyAll` call for the same
532 condition variable in another thread, or until the optional timeout
533 occurs. Once awakened or timed out, it re-acquires the lock and returns.
535 When the *timeout* argument is present and not ``None``, it should be a
536 floating point number specifying a timeout for the operation in seconds
537 (or fractions thereof).
539 When the underlying lock is an :class:`RLock`, it is not released using
540 its :meth:`release` method, since this may not actually unlock the lock
541 when it was acquired multiple times recursively. Instead, an internal
542 interface of the :class:`RLock` class is used, which really unlocks it
543 even when it has been recursively acquired several times. Another internal
544 interface is then used to restore the recursion level when the lock is
549 Wake up a thread waiting on this condition, if any. If the calling thread
550 has not acquired the lock when this method is called, a
551 :exc:`RuntimeError` is raised.
553 This method wakes up one of the threads waiting for the condition
554 variable, if any are waiting; it is a no-op if no threads are waiting.
556 The current implementation wakes up exactly one thread, if any are
557 waiting. However, it's not safe to rely on this behavior. A future,
558 optimized implementation may occasionally wake up more than one thread.
560 Note: the awakened thread does not actually return from its :meth:`wait`
561 call until it can reacquire the lock. Since :meth:`notify` does not
562 release the lock, its caller should.
564 .. method:: notify_all()
567 Wake up all threads waiting on this condition. This method acts like
568 :meth:`notify`, but wakes up all waiting threads instead of one. If the
569 calling thread has not acquired the lock when this method is called, a
570 :exc:`RuntimeError` is raised.
573 .. _semaphore-objects:
578 This is one of the oldest synchronization primitives in the history of computer
579 science, invented by the early Dutch computer scientist Edsger W. Dijkstra (he
580 used :meth:`P` and :meth:`V` instead of :meth:`acquire` and :meth:`release`).
582 A semaphore manages an internal counter which is decremented by each
583 :meth:`acquire` call and incremented by each :meth:`release` call. The counter
584 can never go below zero; when :meth:`acquire` finds that it is zero, it blocks,
585 waiting until some other thread calls :meth:`release`.
588 .. class:: Semaphore([value])
590 The optional argument gives the initial *value* for the internal counter; it
591 defaults to ``1``. If the *value* given is less than 0, :exc:`ValueError` is
594 .. method:: acquire([blocking])
598 When invoked without arguments: if the internal counter is larger than
599 zero on entry, decrement it by one and return immediately. If it is zero
600 on entry, block, waiting until some other thread has called
601 :meth:`release` to make it larger than zero. This is done with proper
602 interlocking so that if multiple :meth:`acquire` calls are blocked,
603 :meth:`release` will wake exactly one of them up. The implementation may
604 pick one at random, so the order in which blocked threads are awakened
605 should not be relied on. There is no return value in this case.
607 When invoked with *blocking* set to true, do the same thing as when called
608 without arguments, and return true.
610 When invoked with *blocking* set to false, do not block. If a call
611 without an argument would block, return false immediately; otherwise, do
612 the same thing as when called without arguments, and return true.
614 .. method:: release()
616 Release a semaphore, incrementing the internal counter by one. When it
617 was zero on entry and another thread is waiting for it to become larger
618 than zero again, wake up that thread.
621 .. _semaphore-examples:
623 :class:`Semaphore` Example
624 ^^^^^^^^^^^^^^^^^^^^^^^^^^
626 Semaphores are often used to guard resources with limited capacity, for example,
627 a database server. In any situation where the size of the resource size is
628 fixed, you should use a bounded semaphore. Before spawning any worker threads,
629 your main thread would initialize the semaphore::
633 pool_sema = BoundedSemaphore(value=maxconnections)
635 Once spawned, worker threads call the semaphore's acquire and release methods
636 when they need to connect to the server::
640 ... use connection ...
644 The use of a bounded semaphore reduces the chance that a programming error which
645 causes the semaphore to be released more than it's acquired will go undetected.
653 This is one of the simplest mechanisms for communication between threads: one
654 thread signals an event and other threads wait for it.
656 An event object manages an internal flag that can be set to true with the
657 :meth:`~Event.set` method and reset to false with the :meth:`clear` method. The
658 :meth:`wait` method blocks until the flag is true.
663 The internal flag is initially false.
668 Return true if and only if the internal flag is true.
672 Set the internal flag to true. All threads waiting for it to become true
673 are awakened. Threads that call :meth:`wait` once the flag is true will
678 Reset the internal flag to false. Subsequently, threads calling
679 :meth:`wait` will block until :meth:`.set` is called to set the internal
682 .. method:: wait([timeout])
684 Block until the internal flag is true. If the internal flag is true on
685 entry, return immediately. Otherwise, block until another thread calls
686 :meth:`.set` to set the flag to true, or until the optional timeout
689 When the timeout argument is present and not ``None``, it should be a
690 floating point number specifying a timeout for the operation in seconds
691 (or fractions thereof).
693 This method returns the internal flag on exit, so it will always return
694 ``True`` except if a timeout is given and the operation times out.
696 .. versionchanged:: 2.7
697 Previously, the method always returned ``None``.
705 This class represents an action that should be run only after a certain amount
706 of time has passed --- a timer. :class:`Timer` is a subclass of :class:`Thread`
707 and as such also functions as an example of creating custom threads.
709 Timers are started, as with threads, by calling their :meth:`start` method. The
710 timer can be stopped (before its action has begun) by calling the :meth:`cancel`
711 method. The interval the timer will wait before executing its action may not be
712 exactly the same as the interval specified by the user.
719 t = Timer(30.0, hello)
720 t.start() # after 30 seconds, "hello, world" will be printed
723 .. class:: Timer(interval, function, args=[], kwargs={})
725 Create a timer that will run *function* with arguments *args* and keyword
726 arguments *kwargs*, after *interval* seconds have passed.
730 Stop the timer, and cancel the execution of the timer's action. This will
731 only work if the timer is still in its waiting stage.
736 Using locks, conditions, and semaphores in the :keyword:`with` statement
737 ------------------------------------------------------------------------
739 All of the objects provided by this module that have :meth:`acquire` and
740 :meth:`release` methods can be used as context managers for a :keyword:`with`
741 statement. The :meth:`acquire` method will be called when the block is entered,
742 and :meth:`release` will be called when the block is exited.
744 Currently, :class:`Lock`, :class:`RLock`, :class:`Condition`,
745 :class:`Semaphore`, and :class:`BoundedSemaphore` objects may be used as
746 :keyword:`with` statement context managers. For example::
750 some_rlock = threading.RLock()
753 print "some_rlock is locked while this executes"
756 .. _threaded-imports:
758 Importing in threaded code
759 --------------------------
761 While the import machinery is thread safe, there are two key
762 restrictions on threaded imports due to inherent limitations in the way
763 that thread safety is provided:
765 * Firstly, other than in the main module, an import should not have the
766 side effect of spawning a new thread and then waiting for that thread in
767 any way. Failing to abide by this restriction can lead to a deadlock if
768 the spawned thread directly or indirectly attempts to import a module.
769 * Secondly, all import attempts must be completed before the interpreter
770 starts shutting itself down. This can be most easily achieved by only
771 performing imports from non-daemon threads created through the threading
772 module. Daemon threads and threads created directly with the thread
773 module will require some other form of synchronization to ensure they do
774 not attempt imports after system shutdown has commenced. Failure to
775 abide by this restriction will lead to intermittent exceptions and
776 crashes during interpreter shutdown (as the late imports attempt to
777 access machinery which is no longer in a valid state).