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