Critical sections and mutexes

Cliff Wells logiplexsoftware at earthlink.net
Wed Oct 24 15:54:23 EDT 2001


On Tuesday 23 October 2001 18:33, brueckd at tbye.com wrote:

> No, "normal" operations on Python objects are atomic as far as threads are
> concerned. There are some very good reasons for using locking/signaling
> (to sequentialize access to a function, to keep a worker thread asleep
> until you use a semaphore to signal it to awake, etc), but it's not always
> a requirement. Consider a simple producer/consumer situation:

True, I may have overstated it a bit, however, I would expect that the 
typical multi-threaded application is going to do things that require more 
than a single-line of python to manipulate data, i.e. len() prior to append() 
or pop() or whatever.  If another thread alters the list (or other mutable 
object) between the call to len() and append() (or whatever) then the value 
returned from len() may be invalid.  Unless you are a very careful 
programmer, you are asking for trouble that can be difficult to track down.  
In this case, the person asking for help clearly has little experience with 
threads and wrapping all shared objects in locks would be a safer choice for 
him.

Regards,

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308




More information about the Python-list mailing list