S.Z. wrote:
> Robert Klemme wrote:
>> S.Z. wrote:
>>> undef :to_s, :taint, :clone;
>>> Now method_missing() can operate.
>> And which method do you invoke then if you undefined all those
>> methods?
> If I invoke to_s() on Sync object, then method_missing()  will be
> called because to_s() has been undefined for Sync class.
> method_missing() can do all I want to be done.

Well yes, but from what I understand from your postings your aim is to
make each method synchronized automatically.  Or are you saying that you
want to use a delegate pattern where method_missing is used to call the
original instance's method synchronized?

> Robert Klemme wrote:
>> S.Z. wrote:
>>> Any transaction on an object can be treated as a single method call.
>> Certainly not!  It might in a many scenarios but there's also a lot
>> scenarios where this does not apply.  This statement as a general
>> statement is wrong.
> Would you show an example in which this does not apply?

I did already.  Every scenario where at least two method calls on the same
or multiple objects have to be atomic with regard to other threads'
activities.

> Robert Klemme wrote:
>> S.Z. wrote:
>>> Transaction's body can be known only at runtime; but it is not a
>>> problem in Ruby.
>> What are you trying to say here?
> Excuse my poor English.
> Transaction is not a method call, rather a context for several method
> calls.
> But, if we can put these calls to single batch and invoke it then
> transacton is just a method call, except for begin/commit semantics.
> In Ruby we can easily create such a batch.

You have that feature already with Mutex#synchronized and
Monitor#synchronized.  There's also a variant as mixin (see doc ref
below).

> Robert Klemme wrote:
>> Built in sychronization of every
>> method is pointless because you never get the class without
>> synchronization overhead.
> It is obvious.
> Rather having an ordinary object I need to construct the synchronized
> one without the use of errorprone external mutexes and randevous.

So you're using Java's delegation approach with
Collection.synchronizedList() etc., i.e. you have a wrapper class that
does the synchronization and then delegates each method call to the real
object.

> As the first step, I have created Sync class to hold the object and
> the sync semantics.

You don't need to create that on your own.  It's already there:
http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/index.html
http://www.ruby-doc.org/stdlib/libdoc/monitor/rdoc/index.html

> In the simplest case of read/write unordered buffer only per-method
> synchronization is needed and therefore Sync class can solve the task.

Yes, but only in these cases.

Regards

    robert