Critical sections and mutexes

[Cliff Wells]

On Wednesday 24 October 2001 19:56, brueckd at tbye.com wrote:
>
> I do see your point, but I think of it from the opposite point of view: a
> newbie learning about threads would be thrilled to get a simple
> producer/consumer program working to play around with.  Once they see how
> cool it is, then you move on to teaching them about locking problems,
> mutexes, etc. And hopefully, they played with it enough already to get
> bitten by a problem so that they really understand the lesson.

Yes, I can see your point here (when I took CS classes we were often taught 
that way: do it wrong, then learn language features that help do it right).  
If this were a classroom, then I would probably concede at this point.  
However, without the luxury of being able to hold someone's hand and lead 
them step-by-step, I think it's best to just give them the most appropriate 
information for solving their immediate problem.  

I've found that it's far more frustrating to have what appears to be a 
correct program fail for some obscure reason (as your example would if one 
started modifying it to any significant degree - and a user trying to 
understand the mechanics of the code would undoubtedly do so).  Any CS book 
that discusses threading (in the general sense) will emphasize the need for 
locking shared resources. 

Not only that, but the code you supplied may have worked, but it also drives 
CPU utilization through the roof (as you mentioned yourself, locks can be 
used to avoid busy loops) so a newbie testing such code might be immediately 
put off from further investigation into threads simply due to apparent 
performance reasons.  Another good reason to supply correct code, not just 
the simplest code.

> I think it discourages newbies to bombard them with all the locking issues
> up front, and it's a real strength of Python (especially for programming
> newbies) that you can often "get away" with no explicit thread-safety
> measures. Were your first multithreaded programs threadsafe? Mine sure
> weren't. But it was okay because at that point it was much more important

Actually, the reason I started using Python was because I needed to write a 
multi-threaded program on Windows and Cygwin gcc didn't support threads at 
the time (and I didn't want to use fork).  So my very first Python program 
was also my very first threaded program _and_ my first network program.  It 
was in fact, thread-safe and only took around a week to get working (if you 
don't count feature-creep).  I don't think locking is such a difficult 
concept to grasp (at least no more than threading itself), and is fundamental 
to threading.  

> to get something working. This is no different than any of the other
> newbie-friendly aspects of Python (no type decls, no memory management,
> etc.) - people can get up to speed quickly because they do have to get
> overwhelmed with the details all at the start.

Yes, one of the appealing things about Python is that it tends to make 
concepts that are difficult to master in other languages appear simple.  
However, it doesn't (and shouldn't) encourage you to adopt bad programming 
practices just because you can (I _could_ use the variable x to hold an int, 
a string and a list at different times in the same function, but it would be 
bad).

I don't feel locking is a detail so much as a fundamental aspect of 
threading.  The fact that you can get away with it (in special cases) under 
current implementations of Python is not really a good reason to do it.  It's 
my feeling that making high-level code rely on low-level implementation 
details of an interpreter or compiler is always a bad idea (in any language - 
look at all the non-portable C programs that exist [and the OS's that have 
hacks to support them] due to programmer's using implementation-specific 
features of a particular platform or compiler).  

Regards,

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