[Python-Dev] Threading and synchronization primitives (original) (raw)

skip@pobox.com skip at pobox.com
Thu Oct 13 18:07:07 CEST 2005 

Greg> All right then, how about putting it in a module called
Greg> threadutils or something like that, which is clearly related to
Greg> threading, but is open for the addition of future thread-related
Greg> features that might arise.

Then Lock, RLock, Semaphore, etc belong there instead of in threading don't they?

We have two things here, the basic thread object and the stuff it does (run, start, etc) and the synchronization primitives. Thread objects come in two levels of abstraction: thread.thread and threading.Thread. The synchronization primitives come in three levels of abstraction: thread.lock, threading.{Lock,Semaphore,...} and Queue.Queue. Each level of abstraction builds on the level below.

In the typical case I think we want to encourage programmers to use the highest levels of abstraction available and leave the lower level stuff to the real pros. That means most programmers using threads should use threading.Thread and Queue.Queue. Partitioning the various classes to different modules might look like this:

    Module        Thread Classes            Sync Primitives
    ------        --------------            ---------------
    _thread       thread                    lock
    threadutils                             Lock, RLock, Semaphore
    thread        Thread                    Queue

Programmers would clearly be discouraged from using the _thread module (currently thread). The typical case would be to import the thread module (currently threading) and use its Thread and Queue objects. For specialized use the threadutils programmer can import the threadutils module to get at the synchronization primitives it contains.

Skip

More information about the Python-Dev mailing list