The reliability of python threads

[John Nagle]

Carl J. Van Arsdall wrote:
> Chris Mellon wrote:
> 
>> On 24 Jan 2007 18:21:38 GMT, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
>>  
>>
>>> [snip]
>>>
>>>     
>>
>>
>> I'm aware of the issues with the POSIX threading model. I still stand
>> by my statement - bringing up the problems with the provability of
>> correctness in the POSIX model amounts to FUD in a discussion of
>> actual problems with actual code.
>>
>> Logic and programming errors in user code are far more likely to be
>> the cause of random errors in a threaded program than theoretical
>> (I've never come across a case in practice) issues with the POSIX
>> standard.
>>   
> 
> Yea, typically I would think that.  The problem I am seeing is 
> incredibly intermittent.  Like a simple pyro server that gives me a 
> problem maybe every three or four months.  Just something funky will 
> happen to the state of the whole thing, some bad data, i'm having an 
> issue tracking it down and some more experienced programmers mentioned 
> that its most likely a race condition.  

     Right.  You're at MonteVista, which does real-time Linux systems
and support.  There will be people there who thoroughly understand
thread issues.  (I've used QNX for real time, but MonteVista has
made progress since in recent years.)

     The Python thread documentation is kind of vague about how
well the Python primitives are protected against concurrency problems.
For example, do you have to protect basic types like lists
and hashes against concurrent access?  Is "pop" atomic?
(It is in "dequeue", but what about regular lists?)
Can you crash Python from within Python via concurrency errors?
Does the garbage collector run concurrently or does it freeze
all threads?  What's different depending upon whether you're using
real OS threads or simulated Python threads?

					John Nagle