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