S.Z. wrote:
> Robert Klemme wrote:
>> S.Z. wrote:
>>> What is the better choice?
>>
>> You can iterate all instance methods, alias each one and create a
>> new one calling the original one synchronized.  Delegate might be
>> helpful, too.
> Eurica!
> I need not to define, but rather to undefine the Object's methods:
> undef :to_s, :taint, :clone;
> Now method_missing() can operate.

And which method do you invoke then if you undefined all those methods?

>> Note though that automatically synchronizaton of each method is not
>> necessarily going to make your program thread safe.  Every
>> transaction that involves more than one method invocation won't be
>> thread safe with this approach - in this case you need explicit
>> external synchronization
> 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.

> Transaction's body can be known only at runtime; but it is not a
> problem in Ruby.

What are you trying to say here?

>> Sun stepped away from
>> full synchronization (Vector, StringBuffer) and added classes that
>> do not employ method level synchronization (ArrayList,
>> StringBuilder), which is more performant.
> This approach is erroprone, I think...

Not at all.  It's exactly the way to go.  Built in sychronization of every
method is pointless because you never get the class without
synchronization overhead.  This can have serious impact on applications as
every synchronized necessitates synchronization of thread local memory
(there are some nice articles on the web on how Java VM handles
concurrency, synchronization - look for "JVM memory model").

Honestly, I'm not sure that you completely grokked concurrency.  I suggest
you get yourself a copy of "Concurrent Programming in Java" if you want to
dig deeper into the matter

http://www.amazon.com/exec/obidos/tg/detail/-/0201310090

Kind regards

    robert