Home Original page

Critical sections and mutexes

Cliff Wells logiplexsoftware at earthlink.net
Fri Oct 26 13:04:33 EDT 2001 
On Thursday 25 October 2001 11:57, brueckd at tbye.com wrote:

> Hold on... the definition of a "bad" programming practice is certainly not
> universal. Not deleting memory you allocated is bad in C; that doesn't
> make it bad in Python. Yes there are principles that apply to many
> languages, after lots of multithreaded Python programs I've come to find
> that "always use explicit locking" isn't one of them, that's all.

True, but it's almost always safe to not deallocate in Python - it's not 
always safe to forego explicit locks (and we may disagree, but it's at least 
arguable that threaded code not requiring locks is atypical).

> This is baggage you're bringing with you from previous languages - we all
> do this to one degree or another. Once again, though, what may be an
> "always" rule in C is a good rule of thumb but not as strict in Python:
> for line in open('ages.txt').readlines():
>   name, age = line.strip().split()
>   age = int(age)
>
> "Always bad in language X" does not imply "Always bad in Python".

Granted.  Once again, I may be guilty of overstatement (I do the above on a 
regular basis - casting to int() that is, not overstatement.  Well, maybe 
both =).  I was thinking more along the lines of using it for different types 
in unrelated contexts where x means one thing at one time and then something 
else later on.

> > I don't feel locking is a detail so much as a fundamental aspect of
> > threading.
>
> I'm not disagreeing with you, Cliff. At issue is the fact that it is so
> fundamental that the interpreter already does some of it for you.
>
> >  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.
>
> Do you explicitly close every file object you open? I sure don't. And when
> the time comes that I do have to close the file myself, I certainly don't
> feel that all those other times I'm getting away with something. It's just
> how things work and it's very convenient.

Actually I do explicitly close every file - I realize it's not really 
necessary, but I feel it's a good habit, and there are times (be they few and 
far between) when leaving a file open can cause problems (for long-running 
tasks where the handle never goes out of scope).

I do recognize that Python delivers us from many of the programming tasks 
that other languages require (which is why we're both here =), but I don't 
feel that the thread-safety provided by the interpreter is enough (at least 
at the moment) to recommend ever not using locks.  Besides, even in the cases 
where you can avoid them, I can see no real benefit to doing so.  Even if 
your data is safe, other issues such as performance or synchronization will 
usually mandate their use anyway.

> > 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
>
> I wholeheartedly agree that reliance on low-level implementation details
> can be a Bad Thing. I don't, however, see this as all that low-level (in
> fact, always requiring explicit locking even on simple resource access
> smacks of just the type of annoying task that Python helps you avoid).
>
> The fact that the Python core is inherently thread-safe is a very
> high-level concept, and is a fundamental part of threading support in
> Python. It is completely in line with other housekeeping/safety features
> of Python. That type of basic thread safety will not go away. The GIL
> might, but its replacement would still be a threadsafe core, and so you'd
> end up with the same thing.

You are probably correct on this point, I expect the thread-safety will only 
improve, but at the moment it's still not enough.

BTW, Dave, I would like to say that I have learned a few things on this topic 
that I wasn't aware of - thanks for the interesting discussion.

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