From: Robert Klemme <bob.news@...>
Date: 2005-09-27T22:26:44+09:00
Subject: Re: tuple-space patterns and lock-free data structures (was: Ruby Threads 101)

Zed A. Shaw wrote:
> Ben,
>
> I had a lot of fun implementing the following patterns as a way of
> avoiding almost all Thread primitives in a distributed video
> processing system and boosting performance quite a bit:
>
> http://alumnus.caltech.edu/~croft/research/agent/tuplespaces/
>
> In fact, Ruby comes with a nice tuple space implementation, so you
> could take the above patterns, implement single instance versions, and
> then try to distribute them.

As far as I can see the idea is basically to have a synchronized
repository (typically a queue) where several workers can fetch their tasks
from and during working on the task there is no synchronization needed (in
Doug Lea terms "lightweight processing framework" with "thread
confinement").  Not really fancy or did I miss something?

> Those patterns are also good examples of why the logical proof of
> single machine thread primitives does not instantly extend to
> distributed processing.  They are much simpler to use and do
> exactly the same thing as distributed locking with nothing more than
> simple tuple-space semantics rather than the complicated mutex and
> semaphore semantics.

Honestly, I don't think mutexes and semaphores are out of business simply
because you don't see them directly.  Concurrency - however done - adds
significantly to the complexity of an application and people creating such
applications shoule be well aware of the basic problems they have to solve
to make them reliably do what they want.

> I would also take a look at the work done on lock-free data structures
> and algorithms.  Lots of really great stuff that basically shows you
> don't need locking on many data structures.  Even more proof
> that 1970's locking technology needs to be rethunk.

Hmm...  Still you need *some* form of synchronization / locking.  The
point is to make it as efficient as possible, i.e., try to reduce
synchronization points.  I don't know what exactly you mean by "1970's
locking technology" but I think the basics didn't change that much from
the 70's on.

> My favorite fun project is doing a Replicated-Worker pattern with just
> message queues.  Sure the Queue needs locking, but why do you need to
> know that?

In oder to understand what you are doing.  People that apply this pattern
(see above) need to know why it's working IMHO.

Kind regards

    robert