This module constructs higher-level threading interfaces on top of the
lower level thread module.
The dummy_threading module is provided for
situations where threading cannot be used because
thread is missing.
This module defines the following functions and objects:
-
Return the number of currently active Thread objects.
The returned count is equal to the length of the list returned by
enumerate().
A function that returns the number of currently active threads.
-
A factory function that returns a new condition variable object.
A condition variable allows one or more threads to wait until they
are notified by another thread.
-
Return the current Thread object, corresponding to the
caller's thread of control. If the caller's thread of control was not
created through the
threading module, a dummy thread object with limited functionality
is returned.
-
Return a list of all currently active Thread objects.
The list includes daemonic threads, dummy thread objects created
by currentThread(), and the main thread. It excludes terminated
threads and threads that have not yet been started.
-
A factory function that returns a new event object. An event manages
a flag that can be set to true with the set() method and
reset to false with the clear() method. The wait()
method blocks until the flag is true.
- class local
-
A class that represents thread-local data. Thread-local data are data
whose values are thread specific. To manage thread-local data, just
create an instance of local (or a subclass) and store
attributes on it:
mydata = threading.local()
mydata.x = 1
The instance's values will be different for separate threads.
For more details and extensive examples, see the documentation string
of the _threading_local module.
New in version 2.4.
-
A factory function that returns a new primitive lock object. Once
a thread has acquired it, subsequent attempts to acquire it block,
until it is released; any thread may release it.
-
A factory function that returns a new reentrant lock object.
A reentrant lock must be released by the thread that acquired it.
Once a thread has acquired a reentrant lock, the same thread may
acquire it again without blocking; the thread must release it once
for each time it has acquired it.
-
A factory function that returns a new semaphore object. A
semaphore manages a counter representing the number of release()
calls minus the number of acquire() calls, plus an initial value.
The acquire() method blocks if necessary until it can return
without making the counter negative. If not given, value defaults to
1.
| BoundedSemaphore( |
[value]) |
-
A factory function that returns a new bounded semaphore object. A bounded
semaphore checks to make sure its current value doesn't exceed its initial
value. If it does, ValueError is raised. In most situations
semaphores are used to guard resources with limited capacity. If the
semaphore is released too many times it's a sign of a bug. If not given,
value defaults to 1.
- class Thread
-
A class that represents a thread of control. This class can be safely
subclassed in a limited fashion.
- class Timer
-
A thread that executes a function after a specified interval has passed.
-
Set a trace function for all threads started
from the threading module. The func will be passed to
sys.settrace() for each thread, before its run()
method is called.
New in version 2.3.
-
Set a profile function for all threads started
from the threading module. The func will be passed to
sys.setprofile() for each thread, before its run()
method is called.
New in version 2.3.
Detailed interfaces for the objects are documented below.
The design of this module is loosely based on Java's threading model.
However, where Java makes locks and condition variables basic behavior
of every object, they are separate objects in Python. Python's Thread
class supports a subset of the behavior of Java's Thread class;
currently, there are no priorities, no thread groups, and threads
cannot be destroyed, stopped, suspended, resumed, or interrupted. The
static methods of Java's Thread class, when implemented, are mapped to
module-level functions.
All of the methods described below are executed atomically.
Release 2.4.1, documentation updated on 30 March 2005.
See About this document... for information on suggesting changes.
