Re: [tlug] STM (was: Re: work times & accommodation @tokyo)

["Stephen J. Turnbull" <stephen@example.com>]

Attila Kinali writes:
 > On Sun, 03 Aug 2008 05:39:29 +0900
 > "Stephen J. Turnbull" <stephen@example.com> wrote:
 > > Attila Kinali writes:

 > >  > As an example, imagine two tasks doing some work on exactly the
 > >  > same data set in a loop, over and over again. Task B takes longer
 > >  > than task A to finish its work.
 > > 
 > > The Doctor says, "put down the hammer".  Of course you use some kind
 > > of queue in this case.
 > > 
 > > But no matter what you do, you're not going to get much better
 > > performance than if you combine the tasks in the same loop instead of
 > > running them in separate threads/processes.
 > 
 > Exactly, but unfortunately, there are cases where you cannot
 > do that and you have to be able to have updates from different
 > tasks.

ButI do not want to suggest that you *should* put them in the same
loop.  There are better reasons than "can't" for having separate
tasks.  My point is that STM is a performance hack in any case (cf the
Don Hopwood comment I quoted about no-shared-state implementations of
transactions), and if you have a situation like this you should be
using queues of some kind, not shared state.

And if you can't afford the performance hit, Curt will tell you
"you're f*cked". ;-)

BTW, one of the reasons I admire Guido van Rossum (and the Python dev
process as a whole) so much is that he strikes the necessary balance
so well.  He has been resisting putting much threading support into
Python for many years (at least the 4 years or so I've been following
python-dev), for precisely these reasons.  Python is fast, as fast as
Perl, but if you really need shared-state threading for performance
reasons, Python probably is not your language anyway.  So GvR refuses
to cater to those who want to add tons of complexity to support such
features.