[2] | 1 | :mod:`threading` --- Higher-level threading interface
|
---|
| 2 | =====================================================
|
---|
| 3 |
|
---|
| 4 | .. module:: threading
|
---|
| 5 | :synopsis: Higher-level threading interface.
|
---|
| 6 |
|
---|
[391] | 7 | **Source code:** :source:`Lib/threading.py`
|
---|
[2] | 8 |
|
---|
[391] | 9 | --------------
|
---|
| 10 |
|
---|
[2] | 11 | This module constructs higher-level threading interfaces on top of the lower
|
---|
| 12 | level :mod:`thread` module.
|
---|
| 13 | See also the :mod:`mutex` and :mod:`Queue` modules.
|
---|
| 14 |
|
---|
| 15 | The :mod:`dummy_threading` module is provided for situations where
|
---|
| 16 | :mod:`threading` cannot be used because :mod:`thread` is missing.
|
---|
| 17 |
|
---|
| 18 | .. note::
|
---|
| 19 |
|
---|
[391] | 20 | Starting with Python 2.6, this module provides :pep:`8` compliant aliases and
|
---|
[2] | 21 | properties to replace the ``camelCase`` names that were inspired by Java's
|
---|
| 22 | threading API. This updated API is compatible with that of the
|
---|
| 23 | :mod:`multiprocessing` module. However, no schedule has been set for the
|
---|
| 24 | deprecation of the ``camelCase`` names and they remain fully supported in
|
---|
| 25 | both Python 2.x and 3.x.
|
---|
| 26 |
|
---|
| 27 | .. note::
|
---|
| 28 |
|
---|
| 29 | Starting with Python 2.5, several Thread methods raise :exc:`RuntimeError`
|
---|
| 30 | instead of :exc:`AssertionError` if called erroneously.
|
---|
| 31 |
|
---|
[391] | 32 | .. impl-detail::
|
---|
[2] | 33 |
|
---|
[391] | 34 | In CPython, due to the :term:`Global Interpreter Lock`, only one thread
|
---|
| 35 | can execute Python code at once (even though certain performance-oriented
|
---|
| 36 | libraries might overcome this limitation).
|
---|
| 37 | If you want your application to make better use of the computational
|
---|
| 38 | resources of multi-core machines, you are advised to use
|
---|
| 39 | :mod:`multiprocessing`. However, threading is still an appropriate model
|
---|
| 40 | if you want to run multiple I/O-bound tasks simultaneously.
|
---|
| 41 |
|
---|
| 42 |
|
---|
[2] | 43 | This module defines the following functions and objects:
|
---|
| 44 |
|
---|
| 45 | .. function:: active_count()
|
---|
| 46 | activeCount()
|
---|
| 47 |
|
---|
| 48 | Return the number of :class:`Thread` objects currently alive. The returned
|
---|
| 49 | count is equal to the length of the list returned by :func:`.enumerate`.
|
---|
| 50 |
|
---|
[391] | 51 | .. versionchanged:: 2.6
|
---|
| 52 | Added ``active_count()`` spelling.
|
---|
[2] | 53 |
|
---|
[391] | 54 |
|
---|
[2] | 55 | .. function:: Condition()
|
---|
| 56 | :noindex:
|
---|
| 57 |
|
---|
| 58 | A factory function that returns a new condition variable object. A condition
|
---|
| 59 | variable allows one or more threads to wait until they are notified by another
|
---|
| 60 | thread.
|
---|
| 61 |
|
---|
[391] | 62 | See :ref:`condition-objects`.
|
---|
[2] | 63 |
|
---|
[391] | 64 |
|
---|
[2] | 65 | .. function:: current_thread()
|
---|
| 66 | currentThread()
|
---|
| 67 |
|
---|
| 68 | Return the current :class:`Thread` object, corresponding to the caller's thread
|
---|
| 69 | of control. If the caller's thread of control was not created through the
|
---|
| 70 | :mod:`threading` module, a dummy thread object with limited functionality is
|
---|
| 71 | returned.
|
---|
| 72 |
|
---|
[391] | 73 | .. versionchanged:: 2.6
|
---|
| 74 | Added ``current_thread()`` spelling.
|
---|
[2] | 75 |
|
---|
[391] | 76 |
|
---|
[2] | 77 | .. function:: enumerate()
|
---|
| 78 |
|
---|
| 79 | Return a list of all :class:`Thread` objects currently alive. The list
|
---|
| 80 | includes daemonic threads, dummy thread objects created by
|
---|
| 81 | :func:`current_thread`, and the main thread. It excludes terminated threads
|
---|
| 82 | and threads that have not yet been started.
|
---|
| 83 |
|
---|
| 84 |
|
---|
| 85 | .. function:: Event()
|
---|
| 86 | :noindex:
|
---|
| 87 |
|
---|
| 88 | A factory function that returns a new event object. An event manages a flag
|
---|
| 89 | that can be set to true with the :meth:`~Event.set` method and reset to false
|
---|
| 90 | with the :meth:`clear` method. The :meth:`wait` method blocks until the flag
|
---|
| 91 | is true.
|
---|
| 92 |
|
---|
[391] | 93 | See :ref:`event-objects`.
|
---|
[2] | 94 |
|
---|
[391] | 95 |
|
---|
[2] | 96 | .. class:: local
|
---|
| 97 |
|
---|
| 98 | A class that represents thread-local data. Thread-local data are data whose
|
---|
| 99 | values are thread specific. To manage thread-local data, just create an
|
---|
| 100 | instance of :class:`local` (or a subclass) and store attributes on it::
|
---|
| 101 |
|
---|
| 102 | mydata = threading.local()
|
---|
| 103 | mydata.x = 1
|
---|
| 104 |
|
---|
| 105 | The instance's values will be different for separate threads.
|
---|
| 106 |
|
---|
| 107 | For more details and extensive examples, see the documentation string of the
|
---|
| 108 | :mod:`_threading_local` module.
|
---|
| 109 |
|
---|
| 110 | .. versionadded:: 2.4
|
---|
| 111 |
|
---|
| 112 |
|
---|
| 113 | .. function:: Lock()
|
---|
| 114 |
|
---|
| 115 | A factory function that returns a new primitive lock object. Once a thread has
|
---|
| 116 | acquired it, subsequent attempts to acquire it block, until it is released; any
|
---|
| 117 | thread may release it.
|
---|
| 118 |
|
---|
[391] | 119 | See :ref:`lock-objects`.
|
---|
[2] | 120 |
|
---|
[391] | 121 |
|
---|
[2] | 122 | .. function:: RLock()
|
---|
| 123 |
|
---|
| 124 | A factory function that returns a new reentrant lock object. A reentrant lock
|
---|
| 125 | must be released by the thread that acquired it. Once a thread has acquired a
|
---|
| 126 | reentrant lock, the same thread may acquire it again without blocking; the
|
---|
| 127 | thread must release it once for each time it has acquired it.
|
---|
| 128 |
|
---|
[391] | 129 | See :ref:`rlock-objects`.
|
---|
[2] | 130 |
|
---|
[391] | 131 |
|
---|
[2] | 132 | .. function:: Semaphore([value])
|
---|
| 133 | :noindex:
|
---|
| 134 |
|
---|
| 135 | A factory function that returns a new semaphore object. A semaphore manages a
|
---|
| 136 | counter representing the number of :meth:`release` calls minus the number of
|
---|
| 137 | :meth:`acquire` calls, plus an initial value. The :meth:`acquire` method blocks
|
---|
| 138 | if necessary until it can return without making the counter negative. If not
|
---|
| 139 | given, *value* defaults to 1.
|
---|
| 140 |
|
---|
[391] | 141 | See :ref:`semaphore-objects`.
|
---|
[2] | 142 |
|
---|
[391] | 143 |
|
---|
[2] | 144 | .. function:: BoundedSemaphore([value])
|
---|
| 145 |
|
---|
| 146 | A factory function that returns a new bounded semaphore object. A bounded
|
---|
| 147 | semaphore checks to make sure its current value doesn't exceed its initial
|
---|
| 148 | value. If it does, :exc:`ValueError` is raised. In most situations semaphores
|
---|
| 149 | are used to guard resources with limited capacity. If the semaphore is released
|
---|
| 150 | too many times it's a sign of a bug. If not given, *value* defaults to 1.
|
---|
| 151 |
|
---|
| 152 |
|
---|
| 153 | .. class:: Thread
|
---|
[391] | 154 | :noindex:
|
---|
[2] | 155 |
|
---|
| 156 | A class that represents a thread of control. This class can be safely
|
---|
| 157 | subclassed in a limited fashion.
|
---|
| 158 |
|
---|
[391] | 159 | See :ref:`thread-objects`.
|
---|
[2] | 160 |
|
---|
[391] | 161 |
|
---|
[2] | 162 | .. class:: Timer
|
---|
[391] | 163 | :noindex:
|
---|
[2] | 164 |
|
---|
| 165 | A thread that executes a function after a specified interval has passed.
|
---|
| 166 |
|
---|
[391] | 167 | See :ref:`timer-objects`.
|
---|
[2] | 168 |
|
---|
[391] | 169 |
|
---|
[2] | 170 | .. function:: settrace(func)
|
---|
| 171 |
|
---|
| 172 | .. index:: single: trace function
|
---|
| 173 |
|
---|
| 174 | Set a trace function for all threads started from the :mod:`threading` module.
|
---|
| 175 | The *func* will be passed to :func:`sys.settrace` for each thread, before its
|
---|
[391] | 176 | :meth:`~Thread.run` method is called.
|
---|
[2] | 177 |
|
---|
| 178 | .. versionadded:: 2.3
|
---|
| 179 |
|
---|
| 180 |
|
---|
| 181 | .. function:: setprofile(func)
|
---|
| 182 |
|
---|
| 183 | .. index:: single: profile function
|
---|
| 184 |
|
---|
| 185 | Set a profile function for all threads started from the :mod:`threading` module.
|
---|
| 186 | The *func* will be passed to :func:`sys.setprofile` for each thread, before its
|
---|
[391] | 187 | :meth:`~Thread.run` method is called.
|
---|
[2] | 188 |
|
---|
| 189 | .. versionadded:: 2.3
|
---|
| 190 |
|
---|
| 191 |
|
---|
| 192 | .. function:: stack_size([size])
|
---|
| 193 |
|
---|
| 194 | Return the thread stack size used when creating new threads. The optional
|
---|
| 195 | *size* argument specifies the stack size to be used for subsequently created
|
---|
| 196 | threads, and must be 0 (use platform or configured default) or a positive
|
---|
| 197 | integer value of at least 32,768 (32kB). If changing the thread stack size is
|
---|
| 198 | unsupported, a :exc:`ThreadError` is raised. If the specified stack size is
|
---|
| 199 | invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32kB
|
---|
| 200 | is currently the minimum supported stack size value to guarantee sufficient
|
---|
| 201 | stack space for the interpreter itself. Note that some platforms may have
|
---|
| 202 | particular restrictions on values for the stack size, such as requiring a
|
---|
| 203 | minimum stack size > 32kB or requiring allocation in multiples of the system
|
---|
| 204 | memory page size - platform documentation should be referred to for more
|
---|
| 205 | information (4kB pages are common; using multiples of 4096 for the stack size is
|
---|
| 206 | the suggested approach in the absence of more specific information).
|
---|
| 207 | Availability: Windows, systems with POSIX threads.
|
---|
| 208 |
|
---|
| 209 | .. versionadded:: 2.5
|
---|
| 210 |
|
---|
[391] | 211 |
|
---|
| 212 | .. exception:: ThreadError
|
---|
| 213 |
|
---|
| 214 | Raised for various threading-related errors as described below. Note that
|
---|
| 215 | many interfaces use :exc:`RuntimeError` instead of :exc:`ThreadError`.
|
---|
| 216 |
|
---|
| 217 |
|
---|
[2] | 218 | Detailed interfaces for the objects are documented below.
|
---|
| 219 |
|
---|
| 220 | The design of this module is loosely based on Java's threading model. However,
|
---|
| 221 | where Java makes locks and condition variables basic behavior of every object,
|
---|
| 222 | they are separate objects in Python. Python's :class:`Thread` class supports a
|
---|
| 223 | subset of the behavior of Java's Thread class; currently, there are no
|
---|
| 224 | priorities, no thread groups, and threads cannot be destroyed, stopped,
|
---|
| 225 | suspended, resumed, or interrupted. The static methods of Java's Thread class,
|
---|
| 226 | when implemented, are mapped to module-level functions.
|
---|
| 227 |
|
---|
| 228 | All of the methods described below are executed atomically.
|
---|
| 229 |
|
---|
| 230 |
|
---|
| 231 | .. _thread-objects:
|
---|
| 232 |
|
---|
| 233 | Thread Objects
|
---|
| 234 | --------------
|
---|
| 235 |
|
---|
| 236 | This class represents an activity that is run in a separate thread of control.
|
---|
| 237 | There are two ways to specify the activity: by passing a callable object to the
|
---|
| 238 | constructor, or by overriding the :meth:`run` method in a subclass. No other
|
---|
| 239 | methods (except for the constructor) should be overridden in a subclass. In
|
---|
| 240 | other words, *only* override the :meth:`__init__` and :meth:`run` methods of
|
---|
| 241 | this class.
|
---|
| 242 |
|
---|
| 243 | Once a thread object is created, its activity must be started by calling the
|
---|
| 244 | thread's :meth:`start` method. This invokes the :meth:`run` method in a
|
---|
| 245 | separate thread of control.
|
---|
| 246 |
|
---|
| 247 | Once the thread's activity is started, the thread is considered 'alive'. It
|
---|
| 248 | stops being alive when its :meth:`run` method terminates -- either normally, or
|
---|
| 249 | by raising an unhandled exception. The :meth:`is_alive` method tests whether the
|
---|
| 250 | thread is alive.
|
---|
| 251 |
|
---|
| 252 | Other threads can call a thread's :meth:`join` method. This blocks the calling
|
---|
| 253 | thread until the thread whose :meth:`join` method is called is terminated.
|
---|
| 254 |
|
---|
| 255 | A thread has a name. The name can be passed to the constructor, and read or
|
---|
| 256 | changed through the :attr:`name` attribute.
|
---|
| 257 |
|
---|
| 258 | A thread can be flagged as a "daemon thread". The significance of this flag is
|
---|
| 259 | that the entire Python program exits when only daemon threads are left. The
|
---|
| 260 | initial value is inherited from the creating thread. The flag can be set
|
---|
| 261 | through the :attr:`daemon` property.
|
---|
| 262 |
|
---|
[391] | 263 | .. note::
|
---|
| 264 | Daemon threads are abruptly stopped at shutdown. Their resources (such
|
---|
| 265 | as open files, database transactions, etc.) may not be released properly.
|
---|
| 266 | If you want your threads to stop gracefully, make them non-daemonic and
|
---|
| 267 | use a suitable signalling mechanism such as an :class:`Event`.
|
---|
| 268 |
|
---|
[2] | 269 | There is a "main thread" object; this corresponds to the initial thread of
|
---|
| 270 | control in the Python program. It is not a daemon thread.
|
---|
| 271 |
|
---|
| 272 | There is the possibility that "dummy thread objects" are created. These are
|
---|
| 273 | thread objects corresponding to "alien threads", which are threads of control
|
---|
| 274 | started outside the threading module, such as directly from C code. Dummy
|
---|
| 275 | thread objects have limited functionality; they are always considered alive and
|
---|
| 276 | daemonic, and cannot be :meth:`join`\ ed. They are never deleted, since it is
|
---|
| 277 | impossible to detect the termination of alien threads.
|
---|
| 278 |
|
---|
| 279 |
|
---|
| 280 | .. class:: Thread(group=None, target=None, name=None, args=(), kwargs={})
|
---|
| 281 |
|
---|
| 282 | This constructor should always be called with keyword arguments. Arguments
|
---|
| 283 | are:
|
---|
| 284 |
|
---|
| 285 | *group* should be ``None``; reserved for future extension when a
|
---|
| 286 | :class:`ThreadGroup` class is implemented.
|
---|
| 287 |
|
---|
| 288 | *target* is the callable object to be invoked by the :meth:`run` method.
|
---|
| 289 | Defaults to ``None``, meaning nothing is called.
|
---|
| 290 |
|
---|
| 291 | *name* is the thread name. By default, a unique name is constructed of the
|
---|
| 292 | form "Thread-*N*" where *N* is a small decimal number.
|
---|
| 293 |
|
---|
| 294 | *args* is the argument tuple for the target invocation. Defaults to ``()``.
|
---|
| 295 |
|
---|
| 296 | *kwargs* is a dictionary of keyword arguments for the target invocation.
|
---|
| 297 | Defaults to ``{}``.
|
---|
| 298 |
|
---|
| 299 | If the subclass overrides the constructor, it must make sure to invoke the
|
---|
| 300 | base class constructor (``Thread.__init__()``) before doing anything else to
|
---|
| 301 | the thread.
|
---|
| 302 |
|
---|
| 303 | .. method:: start()
|
---|
| 304 |
|
---|
| 305 | Start the thread's activity.
|
---|
| 306 |
|
---|
| 307 | It must be called at most once per thread object. It arranges for the
|
---|
| 308 | object's :meth:`run` method to be invoked in a separate thread of control.
|
---|
| 309 |
|
---|
[391] | 310 | This method will raise a :exc:`RuntimeError` if called more than once
|
---|
[2] | 311 | on the same thread object.
|
---|
| 312 |
|
---|
| 313 | .. method:: run()
|
---|
| 314 |
|
---|
| 315 | Method representing the thread's activity.
|
---|
| 316 |
|
---|
| 317 | You may override this method in a subclass. The standard :meth:`run`
|
---|
| 318 | method invokes the callable object passed to the object's constructor as
|
---|
| 319 | the *target* argument, if any, with sequential and keyword arguments taken
|
---|
| 320 | from the *args* and *kwargs* arguments, respectively.
|
---|
| 321 |
|
---|
| 322 | .. method:: join([timeout])
|
---|
| 323 |
|
---|
| 324 | Wait until the thread terminates. This blocks the calling thread until the
|
---|
| 325 | thread whose :meth:`join` method is called terminates -- either normally
|
---|
| 326 | or through an unhandled exception -- or until the optional timeout occurs.
|
---|
| 327 |
|
---|
| 328 | When the *timeout* argument is present and not ``None``, it should be a
|
---|
| 329 | floating point number specifying a timeout for the operation in seconds
|
---|
| 330 | (or fractions thereof). As :meth:`join` always returns ``None``, you must
|
---|
| 331 | call :meth:`isAlive` after :meth:`join` to decide whether a timeout
|
---|
| 332 | happened -- if the thread is still alive, the :meth:`join` call timed out.
|
---|
| 333 |
|
---|
| 334 | When the *timeout* argument is not present or ``None``, the operation will
|
---|
| 335 | block until the thread terminates.
|
---|
| 336 |
|
---|
| 337 | A thread can be :meth:`join`\ ed many times.
|
---|
| 338 |
|
---|
| 339 | :meth:`join` raises a :exc:`RuntimeError` if an attempt is made to join
|
---|
| 340 | the current thread as that would cause a deadlock. It is also an error to
|
---|
| 341 | :meth:`join` a thread before it has been started and attempts to do so
|
---|
| 342 | raises the same exception.
|
---|
| 343 |
|
---|
| 344 | .. attribute:: name
|
---|
| 345 |
|
---|
| 346 | A string used for identification purposes only. It has no semantics.
|
---|
| 347 | Multiple threads may be given the same name. The initial name is set by
|
---|
| 348 | the constructor.
|
---|
| 349 |
|
---|
[391] | 350 | .. versionadded:: 2.6
|
---|
| 351 |
|
---|
| 352 | .. method:: getName()
|
---|
| 353 | setName()
|
---|
| 354 |
|
---|
| 355 | Pre-2.6 API for :attr:`~Thread.name`.
|
---|
| 356 |
|
---|
[2] | 357 | .. attribute:: ident
|
---|
| 358 |
|
---|
| 359 | The 'thread identifier' of this thread or ``None`` if the thread has not
|
---|
| 360 | been started. This is a nonzero integer. See the
|
---|
| 361 | :func:`thread.get_ident()` function. Thread identifiers may be recycled
|
---|
| 362 | when a thread exits and another thread is created. The identifier is
|
---|
| 363 | available even after the thread has exited.
|
---|
| 364 |
|
---|
| 365 | .. versionadded:: 2.6
|
---|
| 366 |
|
---|
| 367 | .. method:: is_alive()
|
---|
| 368 | isAlive()
|
---|
| 369 |
|
---|
| 370 | Return whether the thread is alive.
|
---|
| 371 |
|
---|
[391] | 372 | This method returns ``True`` just before the :meth:`run` method starts
|
---|
| 373 | until just after the :meth:`run` method terminates. The module function
|
---|
[2] | 374 | :func:`.enumerate` returns a list of all alive threads.
|
---|
| 375 |
|
---|
[391] | 376 | .. versionchanged:: 2.6
|
---|
| 377 | Added ``is_alive()`` spelling.
|
---|
[2] | 378 |
|
---|
| 379 | .. attribute:: daemon
|
---|
| 380 |
|
---|
| 381 | A boolean value indicating whether this thread is a daemon thread (True)
|
---|
| 382 | or not (False). This must be set before :meth:`start` is called,
|
---|
| 383 | otherwise :exc:`RuntimeError` is raised. Its initial value is inherited
|
---|
| 384 | from the creating thread; the main thread is not a daemon thread and
|
---|
| 385 | therefore all threads created in the main thread default to :attr:`daemon`
|
---|
| 386 | = ``False``.
|
---|
| 387 |
|
---|
| 388 | The entire Python program exits when no alive non-daemon threads are left.
|
---|
| 389 |
|
---|
[391] | 390 | .. versionadded:: 2.6
|
---|
[2] | 391 |
|
---|
[391] | 392 | .. method:: isDaemon()
|
---|
| 393 | setDaemon()
|
---|
| 394 |
|
---|
| 395 | Pre-2.6 API for :attr:`~Thread.daemon`.
|
---|
| 396 |
|
---|
| 397 |
|
---|
[2] | 398 | .. _lock-objects:
|
---|
| 399 |
|
---|
| 400 | Lock Objects
|
---|
| 401 | ------------
|
---|
| 402 |
|
---|
| 403 | A primitive lock is a synchronization primitive that is not owned by a
|
---|
| 404 | particular thread when locked. In Python, it is currently the lowest level
|
---|
| 405 | synchronization primitive available, implemented directly by the :mod:`thread`
|
---|
| 406 | extension module.
|
---|
| 407 |
|
---|
| 408 | A primitive lock is in one of two states, "locked" or "unlocked". It is created
|
---|
| 409 | in the unlocked state. It has two basic methods, :meth:`acquire` and
|
---|
| 410 | :meth:`release`. When the state is unlocked, :meth:`acquire` changes the state
|
---|
| 411 | to locked and returns immediately. When the state is locked, :meth:`acquire`
|
---|
| 412 | blocks until a call to :meth:`release` in another thread changes it to unlocked,
|
---|
| 413 | then the :meth:`acquire` call resets it to locked and returns. The
|
---|
| 414 | :meth:`release` method should only be called in the locked state; it changes the
|
---|
| 415 | state to unlocked and returns immediately. If an attempt is made to release an
|
---|
[391] | 416 | unlocked lock, a :exc:`ThreadError` will be raised.
|
---|
[2] | 417 |
|
---|
| 418 | When more than one thread is blocked in :meth:`acquire` waiting for the state to
|
---|
| 419 | turn to unlocked, only one thread proceeds when a :meth:`release` call resets
|
---|
| 420 | the state to unlocked; which one of the waiting threads proceeds is not defined,
|
---|
| 421 | and may vary across implementations.
|
---|
| 422 |
|
---|
| 423 | All methods are executed atomically.
|
---|
| 424 |
|
---|
| 425 |
|
---|
[391] | 426 | .. method:: Lock.acquire([blocking])
|
---|
[2] | 427 |
|
---|
| 428 | Acquire a lock, blocking or non-blocking.
|
---|
| 429 |
|
---|
[391] | 430 | When invoked with the *blocking* argument set to ``True`` (the default),
|
---|
| 431 | block until the lock is unlocked, then set it to locked and return ``True``.
|
---|
[2] | 432 |
|
---|
[391] | 433 | When invoked with the *blocking* argument set to ``False``, do not block.
|
---|
| 434 | If a call with *blocking* set to ``True`` would block, return ``False``
|
---|
| 435 | immediately; otherwise, set the lock to locked and return ``True``.
|
---|
[2] | 436 |
|
---|
| 437 |
|
---|
| 438 | .. method:: Lock.release()
|
---|
| 439 |
|
---|
| 440 | Release a lock.
|
---|
| 441 |
|
---|
| 442 | When the lock is locked, reset it to unlocked, and return. If any other threads
|
---|
| 443 | are blocked waiting for the lock to become unlocked, allow exactly one of them
|
---|
| 444 | to proceed.
|
---|
| 445 |
|
---|
[391] | 446 | When invoked on an unlocked lock, a :exc:`ThreadError` is raised.
|
---|
[2] | 447 |
|
---|
| 448 | There is no return value.
|
---|
| 449 |
|
---|
| 450 |
|
---|
| 451 | .. _rlock-objects:
|
---|
| 452 |
|
---|
| 453 | RLock Objects
|
---|
| 454 | -------------
|
---|
| 455 |
|
---|
| 456 | A reentrant lock is a synchronization primitive that may be acquired multiple
|
---|
| 457 | times by the same thread. Internally, it uses the concepts of "owning thread"
|
---|
| 458 | and "recursion level" in addition to the locked/unlocked state used by primitive
|
---|
| 459 | locks. In the locked state, some thread owns the lock; in the unlocked state,
|
---|
| 460 | no thread owns it.
|
---|
| 461 |
|
---|
| 462 | To lock the lock, a thread calls its :meth:`acquire` method; this returns once
|
---|
| 463 | the thread owns the lock. To unlock the lock, a thread calls its
|
---|
| 464 | :meth:`release` method. :meth:`acquire`/:meth:`release` call pairs may be
|
---|
| 465 | nested; only the final :meth:`release` (the :meth:`release` of the outermost
|
---|
| 466 | pair) resets the lock to unlocked and allows another thread blocked in
|
---|
| 467 | :meth:`acquire` to proceed.
|
---|
| 468 |
|
---|
| 469 |
|
---|
| 470 | .. method:: RLock.acquire([blocking=1])
|
---|
| 471 |
|
---|
| 472 | Acquire a lock, blocking or non-blocking.
|
---|
| 473 |
|
---|
| 474 | When invoked without arguments: if this thread already owns the lock, increment
|
---|
| 475 | the recursion level by one, and return immediately. Otherwise, if another
|
---|
| 476 | thread owns the lock, block until the lock is unlocked. Once the lock is
|
---|
| 477 | unlocked (not owned by any thread), then grab ownership, set the recursion level
|
---|
| 478 | to one, and return. If more than one thread is blocked waiting until the lock
|
---|
| 479 | is unlocked, only one at a time will be able to grab ownership of the lock.
|
---|
| 480 | There is no return value in this case.
|
---|
| 481 |
|
---|
| 482 | When invoked with the *blocking* argument set to true, do the same thing as when
|
---|
| 483 | called without arguments, and return true.
|
---|
| 484 |
|
---|
| 485 | When invoked with the *blocking* argument set to false, do not block. If a call
|
---|
| 486 | without an argument would block, return false immediately; otherwise, do the
|
---|
| 487 | same thing as when called without arguments, and return true.
|
---|
| 488 |
|
---|
| 489 |
|
---|
| 490 | .. method:: RLock.release()
|
---|
| 491 |
|
---|
| 492 | Release a lock, decrementing the recursion level. If after the decrement it is
|
---|
| 493 | zero, reset the lock to unlocked (not owned by any thread), and if any other
|
---|
| 494 | threads are blocked waiting for the lock to become unlocked, allow exactly one
|
---|
| 495 | of them to proceed. If after the decrement the recursion level is still
|
---|
| 496 | nonzero, the lock remains locked and owned by the calling thread.
|
---|
| 497 |
|
---|
| 498 | Only call this method when the calling thread owns the lock. A
|
---|
| 499 | :exc:`RuntimeError` is raised if this method is called when the lock is
|
---|
| 500 | unlocked.
|
---|
| 501 |
|
---|
| 502 | There is no return value.
|
---|
| 503 |
|
---|
| 504 |
|
---|
| 505 | .. _condition-objects:
|
---|
| 506 |
|
---|
| 507 | Condition Objects
|
---|
| 508 | -----------------
|
---|
| 509 |
|
---|
| 510 | A condition variable is always associated with some kind of lock; this can be
|
---|
| 511 | passed in or one will be created by default. (Passing one in is useful when
|
---|
| 512 | several condition variables must share the same lock.)
|
---|
| 513 |
|
---|
| 514 | A condition variable has :meth:`acquire` and :meth:`release` methods that call
|
---|
| 515 | the corresponding methods of the associated lock. It also has a :meth:`wait`
|
---|
| 516 | method, and :meth:`notify` and :meth:`notifyAll` methods. These three must only
|
---|
| 517 | be called when the calling thread has acquired the lock, otherwise a
|
---|
| 518 | :exc:`RuntimeError` is raised.
|
---|
| 519 |
|
---|
| 520 | The :meth:`wait` method releases the lock, and then blocks until it is awakened
|
---|
| 521 | by a :meth:`notify` or :meth:`notifyAll` call for the same condition variable in
|
---|
| 522 | another thread. Once awakened, it re-acquires the lock and returns. It is also
|
---|
| 523 | possible to specify a timeout.
|
---|
| 524 |
|
---|
| 525 | The :meth:`notify` method wakes up one of the threads waiting for the condition
|
---|
| 526 | variable, if any are waiting. The :meth:`notifyAll` method wakes up all threads
|
---|
| 527 | waiting for the condition variable.
|
---|
| 528 |
|
---|
| 529 | Note: the :meth:`notify` and :meth:`notifyAll` methods don't release the lock;
|
---|
| 530 | this means that the thread or threads awakened will not return from their
|
---|
| 531 | :meth:`wait` call immediately, but only when the thread that called
|
---|
| 532 | :meth:`notify` or :meth:`notifyAll` finally relinquishes ownership of the lock.
|
---|
| 533 |
|
---|
| 534 | Tip: the typical programming style using condition variables uses the lock to
|
---|
| 535 | synchronize access to some shared state; threads that are interested in a
|
---|
| 536 | particular change of state call :meth:`wait` repeatedly until they see the
|
---|
| 537 | desired state, while threads that modify the state call :meth:`notify` or
|
---|
| 538 | :meth:`notifyAll` when they change the state in such a way that it could
|
---|
| 539 | possibly be a desired state for one of the waiters. For example, the following
|
---|
| 540 | code is a generic producer-consumer situation with unlimited buffer capacity::
|
---|
| 541 |
|
---|
| 542 | # Consume one item
|
---|
| 543 | cv.acquire()
|
---|
| 544 | while not an_item_is_available():
|
---|
| 545 | cv.wait()
|
---|
| 546 | get_an_available_item()
|
---|
| 547 | cv.release()
|
---|
| 548 |
|
---|
| 549 | # Produce one item
|
---|
| 550 | cv.acquire()
|
---|
| 551 | make_an_item_available()
|
---|
| 552 | cv.notify()
|
---|
| 553 | cv.release()
|
---|
| 554 |
|
---|
| 555 | To choose between :meth:`notify` and :meth:`notifyAll`, consider whether one
|
---|
| 556 | state change can be interesting for only one or several waiting threads. E.g.
|
---|
| 557 | in a typical producer-consumer situation, adding one item to the buffer only
|
---|
| 558 | needs to wake up one consumer thread.
|
---|
| 559 |
|
---|
| 560 |
|
---|
| 561 | .. class:: Condition([lock])
|
---|
| 562 |
|
---|
| 563 | If the *lock* argument is given and not ``None``, it must be a :class:`Lock`
|
---|
| 564 | or :class:`RLock` object, and it is used as the underlying lock. Otherwise,
|
---|
| 565 | a new :class:`RLock` object is created and used as the underlying lock.
|
---|
| 566 |
|
---|
| 567 | .. method:: acquire(*args)
|
---|
| 568 |
|
---|
| 569 | Acquire the underlying lock. This method calls the corresponding method on
|
---|
| 570 | the underlying lock; the return value is whatever that method returns.
|
---|
| 571 |
|
---|
| 572 | .. method:: release()
|
---|
| 573 |
|
---|
| 574 | Release the underlying lock. This method calls the corresponding method on
|
---|
| 575 | the underlying lock; there is no return value.
|
---|
| 576 |
|
---|
| 577 | .. method:: wait([timeout])
|
---|
| 578 |
|
---|
| 579 | Wait until notified or until a timeout occurs. If the calling thread has not
|
---|
| 580 | acquired the lock when this method is called, a :exc:`RuntimeError` is raised.
|
---|
| 581 |
|
---|
| 582 | This method releases the underlying lock, and then blocks until it is
|
---|
| 583 | awakened by a :meth:`notify` or :meth:`notifyAll` call for the same
|
---|
| 584 | condition variable in another thread, or until the optional timeout
|
---|
| 585 | occurs. Once awakened or timed out, it re-acquires the lock and returns.
|
---|
| 586 |
|
---|
| 587 | When the *timeout* argument is present and not ``None``, it should be a
|
---|
| 588 | floating point number specifying a timeout for the operation in seconds
|
---|
| 589 | (or fractions thereof).
|
---|
| 590 |
|
---|
| 591 | When the underlying lock is an :class:`RLock`, it is not released using
|
---|
| 592 | its :meth:`release` method, since this may not actually unlock the lock
|
---|
| 593 | when it was acquired multiple times recursively. Instead, an internal
|
---|
| 594 | interface of the :class:`RLock` class is used, which really unlocks it
|
---|
| 595 | even when it has been recursively acquired several times. Another internal
|
---|
| 596 | interface is then used to restore the recursion level when the lock is
|
---|
| 597 | reacquired.
|
---|
| 598 |
|
---|
[391] | 599 | .. method:: notify(n=1)
|
---|
[2] | 600 |
|
---|
[391] | 601 | By default, wake up one thread waiting on this condition, if any. If the
|
---|
| 602 | calling thread has not acquired the lock when this method is called, a
|
---|
[2] | 603 | :exc:`RuntimeError` is raised.
|
---|
| 604 |
|
---|
[391] | 605 | This method wakes up at most *n* of the threads waiting for the condition
|
---|
| 606 | variable; it is a no-op if no threads are waiting.
|
---|
[2] | 607 |
|
---|
[391] | 608 | The current implementation wakes up exactly *n* threads, if at least *n*
|
---|
| 609 | threads are waiting. However, it's not safe to rely on this behavior.
|
---|
| 610 | A future, optimized implementation may occasionally wake up more than
|
---|
| 611 | *n* threads.
|
---|
[2] | 612 |
|
---|
[391] | 613 | Note: an awakened thread does not actually return from its :meth:`wait`
|
---|
[2] | 614 | call until it can reacquire the lock. Since :meth:`notify` does not
|
---|
| 615 | release the lock, its caller should.
|
---|
| 616 |
|
---|
| 617 | .. method:: notify_all()
|
---|
| 618 | notifyAll()
|
---|
| 619 |
|
---|
| 620 | Wake up all threads waiting on this condition. This method acts like
|
---|
| 621 | :meth:`notify`, but wakes up all waiting threads instead of one. If the
|
---|
| 622 | calling thread has not acquired the lock when this method is called, a
|
---|
| 623 | :exc:`RuntimeError` is raised.
|
---|
| 624 |
|
---|
[391] | 625 | .. versionchanged:: 2.6
|
---|
| 626 | Added ``notify_all()`` spelling.
|
---|
[2] | 627 |
|
---|
[391] | 628 |
|
---|
[2] | 629 | .. _semaphore-objects:
|
---|
| 630 |
|
---|
| 631 | Semaphore Objects
|
---|
| 632 | -----------------
|
---|
| 633 |
|
---|
| 634 | This is one of the oldest synchronization primitives in the history of computer
|
---|
| 635 | science, invented by the early Dutch computer scientist Edsger W. Dijkstra (he
|
---|
| 636 | used :meth:`P` and :meth:`V` instead of :meth:`acquire` and :meth:`release`).
|
---|
| 637 |
|
---|
| 638 | A semaphore manages an internal counter which is decremented by each
|
---|
| 639 | :meth:`acquire` call and incremented by each :meth:`release` call. The counter
|
---|
| 640 | can never go below zero; when :meth:`acquire` finds that it is zero, it blocks,
|
---|
| 641 | waiting until some other thread calls :meth:`release`.
|
---|
| 642 |
|
---|
| 643 |
|
---|
| 644 | .. class:: Semaphore([value])
|
---|
| 645 |
|
---|
| 646 | The optional argument gives the initial *value* for the internal counter; it
|
---|
| 647 | defaults to ``1``. If the *value* given is less than 0, :exc:`ValueError` is
|
---|
| 648 | raised.
|
---|
| 649 |
|
---|
| 650 | .. method:: acquire([blocking])
|
---|
| 651 |
|
---|
| 652 | Acquire a semaphore.
|
---|
| 653 |
|
---|
| 654 | When invoked without arguments: if the internal counter is larger than
|
---|
| 655 | zero on entry, decrement it by one and return immediately. If it is zero
|
---|
| 656 | on entry, block, waiting until some other thread has called
|
---|
| 657 | :meth:`release` to make it larger than zero. This is done with proper
|
---|
| 658 | interlocking so that if multiple :meth:`acquire` calls are blocked,
|
---|
| 659 | :meth:`release` will wake exactly one of them up. The implementation may
|
---|
| 660 | pick one at random, so the order in which blocked threads are awakened
|
---|
| 661 | should not be relied on. There is no return value in this case.
|
---|
| 662 |
|
---|
| 663 | When invoked with *blocking* set to true, do the same thing as when called
|
---|
| 664 | without arguments, and return true.
|
---|
| 665 |
|
---|
| 666 | When invoked with *blocking* set to false, do not block. If a call
|
---|
| 667 | without an argument would block, return false immediately; otherwise, do
|
---|
| 668 | the same thing as when called without arguments, and return true.
|
---|
| 669 |
|
---|
| 670 | .. method:: release()
|
---|
| 671 |
|
---|
| 672 | Release a semaphore, incrementing the internal counter by one. When it
|
---|
| 673 | was zero on entry and another thread is waiting for it to become larger
|
---|
| 674 | than zero again, wake up that thread.
|
---|
| 675 |
|
---|
| 676 |
|
---|
| 677 | .. _semaphore-examples:
|
---|
| 678 |
|
---|
| 679 | :class:`Semaphore` Example
|
---|
| 680 | ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
---|
| 681 |
|
---|
| 682 | Semaphores are often used to guard resources with limited capacity, for example,
|
---|
[391] | 683 | a database server. In any situation where the size of the resource is fixed,
|
---|
| 684 | you should use a bounded semaphore. Before spawning any worker threads, your
|
---|
| 685 | main thread would initialize the semaphore::
|
---|
[2] | 686 |
|
---|
| 687 | maxconnections = 5
|
---|
| 688 | ...
|
---|
| 689 | pool_sema = BoundedSemaphore(value=maxconnections)
|
---|
| 690 |
|
---|
| 691 | Once spawned, worker threads call the semaphore's acquire and release methods
|
---|
| 692 | when they need to connect to the server::
|
---|
| 693 |
|
---|
| 694 | pool_sema.acquire()
|
---|
| 695 | conn = connectdb()
|
---|
| 696 | ... use connection ...
|
---|
| 697 | conn.close()
|
---|
| 698 | pool_sema.release()
|
---|
| 699 |
|
---|
| 700 | The use of a bounded semaphore reduces the chance that a programming error which
|
---|
| 701 | causes the semaphore to be released more than it's acquired will go undetected.
|
---|
| 702 |
|
---|
| 703 |
|
---|
| 704 | .. _event-objects:
|
---|
| 705 |
|
---|
| 706 | Event Objects
|
---|
| 707 | -------------
|
---|
| 708 |
|
---|
| 709 | This is one of the simplest mechanisms for communication between threads: one
|
---|
| 710 | thread signals an event and other threads wait for it.
|
---|
| 711 |
|
---|
| 712 | An event object manages an internal flag that can be set to true with the
|
---|
| 713 | :meth:`~Event.set` method and reset to false with the :meth:`clear` method. The
|
---|
| 714 | :meth:`wait` method blocks until the flag is true.
|
---|
| 715 |
|
---|
| 716 |
|
---|
| 717 | .. class:: Event()
|
---|
| 718 |
|
---|
| 719 | The internal flag is initially false.
|
---|
| 720 |
|
---|
| 721 | .. method:: is_set()
|
---|
| 722 | isSet()
|
---|
| 723 |
|
---|
| 724 | Return true if and only if the internal flag is true.
|
---|
| 725 |
|
---|
[391] | 726 | .. versionchanged:: 2.6
|
---|
| 727 | Added ``is_set()`` spelling.
|
---|
| 728 |
|
---|
[2] | 729 | .. method:: set()
|
---|
| 730 |
|
---|
| 731 | Set the internal flag to true. All threads waiting for it to become true
|
---|
| 732 | are awakened. Threads that call :meth:`wait` once the flag is true will
|
---|
| 733 | not block at all.
|
---|
| 734 |
|
---|
| 735 | .. method:: clear()
|
---|
| 736 |
|
---|
| 737 | Reset the internal flag to false. Subsequently, threads calling
|
---|
| 738 | :meth:`wait` will block until :meth:`.set` is called to set the internal
|
---|
| 739 | flag to true again.
|
---|
| 740 |
|
---|
| 741 | .. method:: wait([timeout])
|
---|
| 742 |
|
---|
| 743 | Block until the internal flag is true. If the internal flag is true on
|
---|
| 744 | entry, return immediately. Otherwise, block until another thread calls
|
---|
| 745 | :meth:`.set` to set the flag to true, or until the optional timeout
|
---|
| 746 | occurs.
|
---|
| 747 |
|
---|
| 748 | When the timeout argument is present and not ``None``, it should be a
|
---|
| 749 | floating point number specifying a timeout for the operation in seconds
|
---|
| 750 | (or fractions thereof).
|
---|
| 751 |
|
---|
| 752 | This method returns the internal flag on exit, so it will always return
|
---|
| 753 | ``True`` except if a timeout is given and the operation times out.
|
---|
| 754 |
|
---|
| 755 | .. versionchanged:: 2.7
|
---|
| 756 | Previously, the method always returned ``None``.
|
---|
| 757 |
|
---|
| 758 |
|
---|
| 759 | .. _timer-objects:
|
---|
| 760 |
|
---|
| 761 | Timer Objects
|
---|
| 762 | -------------
|
---|
| 763 |
|
---|
| 764 | This class represents an action that should be run only after a certain amount
|
---|
| 765 | of time has passed --- a timer. :class:`Timer` is a subclass of :class:`Thread`
|
---|
| 766 | and as such also functions as an example of creating custom threads.
|
---|
| 767 |
|
---|
[391] | 768 | Timers are started, as with threads, by calling their :meth:`~Timer.start`
|
---|
| 769 | method. The timer can be stopped (before its action has begun) by calling the
|
---|
| 770 | :meth:`~Timer.cancel` method. The interval the timer will wait before
|
---|
| 771 | executing its action may not be exactly the same as the interval specified by
|
---|
| 772 | the user.
|
---|
[2] | 773 |
|
---|
| 774 | For example::
|
---|
| 775 |
|
---|
| 776 | def hello():
|
---|
| 777 | print "hello, world"
|
---|
| 778 |
|
---|
| 779 | t = Timer(30.0, hello)
|
---|
| 780 | t.start() # after 30 seconds, "hello, world" will be printed
|
---|
| 781 |
|
---|
| 782 |
|
---|
| 783 | .. class:: Timer(interval, function, args=[], kwargs={})
|
---|
| 784 |
|
---|
| 785 | Create a timer that will run *function* with arguments *args* and keyword
|
---|
| 786 | arguments *kwargs*, after *interval* seconds have passed.
|
---|
| 787 |
|
---|
| 788 | .. method:: cancel()
|
---|
| 789 |
|
---|
| 790 | Stop the timer, and cancel the execution of the timer's action. This will
|
---|
| 791 | only work if the timer is still in its waiting stage.
|
---|
| 792 |
|
---|
| 793 |
|
---|
| 794 | .. _with-locks:
|
---|
| 795 |
|
---|
| 796 | Using locks, conditions, and semaphores in the :keyword:`with` statement
|
---|
| 797 | ------------------------------------------------------------------------
|
---|
| 798 |
|
---|
| 799 | All of the objects provided by this module that have :meth:`acquire` and
|
---|
| 800 | :meth:`release` methods can be used as context managers for a :keyword:`with`
|
---|
| 801 | statement. The :meth:`acquire` method will be called when the block is entered,
|
---|
| 802 | and :meth:`release` will be called when the block is exited.
|
---|
| 803 |
|
---|
| 804 | Currently, :class:`Lock`, :class:`RLock`, :class:`Condition`,
|
---|
| 805 | :class:`Semaphore`, and :class:`BoundedSemaphore` objects may be used as
|
---|
| 806 | :keyword:`with` statement context managers. For example::
|
---|
| 807 |
|
---|
| 808 | import threading
|
---|
| 809 |
|
---|
| 810 | some_rlock = threading.RLock()
|
---|
| 811 |
|
---|
| 812 | with some_rlock:
|
---|
| 813 | print "some_rlock is locked while this executes"
|
---|
| 814 |
|
---|
| 815 |
|
---|
| 816 | .. _threaded-imports:
|
---|
| 817 |
|
---|
| 818 | Importing in threaded code
|
---|
| 819 | --------------------------
|
---|
| 820 |
|
---|
[391] | 821 | While the import machinery is thread-safe, there are two key restrictions on
|
---|
| 822 | threaded imports due to inherent limitations in the way that thread-safety is
|
---|
| 823 | provided:
|
---|
[2] | 824 |
|
---|
| 825 | * Firstly, other than in the main module, an import should not have the
|
---|
| 826 | side effect of spawning a new thread and then waiting for that thread in
|
---|
| 827 | any way. Failing to abide by this restriction can lead to a deadlock if
|
---|
| 828 | the spawned thread directly or indirectly attempts to import a module.
|
---|
| 829 | * Secondly, all import attempts must be completed before the interpreter
|
---|
| 830 | starts shutting itself down. This can be most easily achieved by only
|
---|
| 831 | performing imports from non-daemon threads created through the threading
|
---|
| 832 | module. Daemon threads and threads created directly with the thread
|
---|
| 833 | module will require some other form of synchronization to ensure they do
|
---|
| 834 | not attempt imports after system shutdown has commenced. Failure to
|
---|
| 835 | abide by this restriction will lead to intermittent exceptions and
|
---|
| 836 | crashes during interpreter shutdown (as the late imports attempt to
|
---|
| 837 | access machinery which is no longer in a valid state).
|
---|