Robert Klemme wrote:
> S.Z. wrote:
>> Below you have mentioned Monitor#synchronized(), that is just a
>> contradiction.
> Where is this a contradiction?
When MonitorMixin is used any transaction can be treated as single
method call (syncronize() with the block as parameter).

> Why can't you use them to implement your Sync class?
I did it with the Mutex. These are the nice lowlevel mechanics, but
using it is erroprone (as it is with any lowlevel mechanic).

> If you're in a producer consumer scenario use a Queue.
Oh no, please, no!
The writer must start to write only if the reader has already started
to read (otherwise data may be lost). I want a better mechanism: 1)
create obj1 and obj2; 2) assign "writer" role to the obj1 and "reader"
to the obj2; 3) create a Queue then attach obj1 and obj2 to it; 4) run
the collaboration.
What I need are more higher level Concurrent Programming Pattens
implemented in Ruby. Using Mutexes to implement these is tedious. I
want more higher level mechanics. A thread need not to wory about
whether it is alone or not, so non-concurrent code can be easily
converted to concurrent one and vise versa.

> Seriously, I really don't know why you think you have to cook something
> completely new while there is lots of stuff that seems to be doing what
> you need.
Because the stuff is not exactly what I need. What I need is a long
story though...

> Maybe it's just a language issue but I have the feeling that
> you always write at most half of what you think.
I have enough words, but have not enough time.

--
    Best regards, S.Z.