From: Robert Feldt <feldt@...>
Date: 2000-10-28T19:20:01+09:00
Subject: [ruby-talk:5933] Re: [RFC] Towards a new synchronisation primitive

On Sat, 28 Oct 2000, Reimer Behrends wrote:

> On Fri, Oct 27, 2000 at 06:13:32AM +0900, hipster wrote:
> > Matz has occasionally expressed his worries about the synchronization
> > primitive used in Ruby today. He asked for suggestions regarding alternate
> > schemes, and guess what, I wrote one. The following discusses object locks,
> > a concept known from Java and others. These object locks would replace the
> > current Thread.critical notation.
> 
> The problem with object locks--and a great many of the other suggestions
> for primitives--is that they are fairly low-level. They represent the
> state of the art for the 1970s, but not for what's possible today. For
> Java's approach in particular, I recommend reading Per Brinch Hansen's
> critique [2] before even thinking of using it. But in general, I suggest
> that prior to changing the language people familiarize themselves with
> the current state of the art for writing reliable concurrent programs,
> specifically the field of coordination languages [1]. If you just need a
> basic mechanism, the current primitives supplied by Thread are more than
> adequate. But none of the proposals that I've seen so far really have
> benefits that exceed those offered by Thread--they are just different
> ways to skin the same cat, and not very good ways, either.
> 
> I apologize if this sounds a bit harsh--but it is my field of research,
> and right now the discussion seems to focus on stuff that was old a
> decade ago.
>
It's good with some expert advice. Would you also be willing to point to
some actual implementations of the new models/ideas you point to?

Can you summarize the benefits of these new ideas in comparison to the
decade-old ones?

Do you think that we can find one "silver bullet" approach in the areas
you point to or do we need to supply primitives at multiple different
abstraction levels?

Aren't coordination languages mostly targeted to massively parallel
systems or do you think they're suitable to single-processor Ruby with
multiple threads?

What about performance issues? Any comparisons between "new" and
"old" approaches?

What about modern COOP approaches like Synchronization rings by DAvid
Holmes? Are they in your opinion mostly a new mix of old ideas or do they
offer anything new (especially in relation to the models/ideas you point
to)?

We'd appreciate if you can help us choose a good design.

Regards,

Robert