Critical sections and mutexes

[Donn Cave]

Quoth David Bolen <db3l at fitlinxx.com>:

| If that's what the newbie wants, they should be pointed to an
| appropriate class (like the Queue) that specifically provides simple
| producer/consumer behavior with all the appropriate locking hidden
| within the class.  I don't think suggesting that they just write their
| own without such locking (which can lead to believing it isn't
| necessary) is to their benefit, even if it makes the problem seem
| simpler.
|
| To my mind, the benefit Python has for newbies is that the typical
| housekeeping required of multithreading applications _and_ the types
| of synchronization that is a fact of life for such applications are
| very simple to use.  And a number of useful classes are provided for
| common scenarios within multithreaded applications.
|
| BTW, one of the reasons I feel strongly about this is that a very
| large percentage of my applications over the years have been
| multithreaded (and I'm a big fan of having the support in the language
| such as Python does) and there are just some things you don't skimp
| on, if you want to do it write, maintainably and with assured behavior
| over time.

An anecdote of sorts on that.  The BeOS user interface graphics API
is inherently multi-threaded.  Every window in an application runs in
its own thread.

BeOS is pretty much dead, sold to Palm if the stockholders ratify it.
In a kind of post-mortem mood one of the complaints that has come up,
even from ex-Be engineers, is that applications are full of bugs because
it's too hard to deal with all these threads safely.  No one seems to
be willing to say that threads aren't at all useful, though.  Anecdote
over.  The moral of the story seems to be that in C++ (it's a C++ API),
you can't easily work safely with threads, so the solution is to limit
your use of threads to the strictly essential.  OK, that's probably
unfair, I imagine the choice of language isn't as important as the
commitment to learning how to program with threads, instead of just
hoping that you can put threads in your program and it will all work
out.  But decent language support for that commitment sure helps.

Incidentally, ever seen how a multi-threaded asynchronous API looks
when you use the Stackless Python continuations feature to turn
message queueing inside out?  May not apply to all systems, but
normally my thread interactions are mediated by message data, used
to dispatch functions.  After posting a message, the thread handler
returns to the dispatcher.  With continuations, the thread handler
can later return to the point where it posted the message, and
"receive" the "function return" message, and the code looks just
like calling any ordinary function.  Brr, I am normally repelled
by magic like that, but it sure makes some multithreaded problems
look easy.

	Donn Cave, donn at drizzle.com