multithreading

[Aahz]

In article <3CF43BA6.5020106 at skippinet.com.au>,
Mark Hammond  <mhammond at skippinet.com.au> wrote:
>Aahz wrote:
>> In article <mailman.1022277883.28027.python-list at python.org>,
>> =?iso-8859-1?q?Fran=E7ois?= Pinard <pinard at iro.umontreal.ca> wrote:
>>>[Aahz]
>>>
>>>>My response is that instead of trying to take advantage of the few
>>>>atomic Python constructs, instead code defensively and always use
>>>>thread-safe mechanisms for passing information.  Because Python has a
>>>>powerful and simple Queue, this is straightforward to accomplish.
>>>
>>>But abusing Queues for very simple things, a bit everywhere, might yield
>>>code bloat, and impinge readability.  This is a bit like if someone was
>>>inviting everyone to abuse fixed point integer arithmetic all over as a
>>>way to program defensively against floating point arithmetic.
>> 
>> 
>> You're both misreading me and overstating your point, IMO.  I completely
>> agree that RLock() is a valuable and necessary tool for managing critical
>> sections of code.  However, I stand by my claim that Queue() should be
>> the primary mechanism for passing data around.  Getting the semantics of
>> Event() and Semaphore() correct (not even talking about Condition() --
>> <shudder>) can be extremely difficult for all but the simplest cases,
>> leading to application deadlock.
>> 
>> Queue is both powerful and simple, and I therefore invoke Python's
>> "There's Only One Way" principle.
>
>You can invoke whatever you like, but it doesn't change anything for 
>anyone else ;)

If you really want to argue about it, go take it up with Tim; I am
merely the acolyte.

>I believe advocating the Queue module as the "one way" is naive.  The 
>Queue module is very useful, and indeed has solved many threading 
>problems in an elegant way for me - however, in my experience, it has 
>been used in less than 50% of the times I have needed mutli-threaded 
>synchronization.

Once again, I'm talking about data passing.  If pure synchronization is
what you're talking about, then Queue isn't necessarily relevant.
However, I'd claim that once data passing is involved, you'd be
hard-pressed to provide an example where what you used instead of Queue
is significantly better.  That's the whole point of the "One Way"
paradigm -- use as few idioms as possible for the low-level solutions to
save brain-power for the higher-order problems.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"In the end, outside of spy agencies, people are far too trusting and
willing to help."  --Ira Winkler