stephan here it is..
initially Author gave this example which is not
thread safe:
i understand why this is not thread safe because here a thread1(say) acquires a key(helper object) for invoking the method and simultaneously another thread2 may come and aquire a key(list) in order to put something in list which breaks the invariant or its atomicity,it is possible as field is public.
am i right?
and then he gives a solution to this...
and explains:
If extending a class to add another atomic operation is fragile because it distributes the locking code for a class over
multiple classes in an object hierarchy, client side locking is even more fragile because it entails putting locking code for
class C into classes that are totally unrelated to C. Exercise care when using client side locking on classes that do not
commit to their locking strategy.
Client side locking has a lot in common with class extension they both couple the behavior of the derived class to the
implementation of the base class. Just as extension violates encapsulation of implementation [EJ Item 14], client side
locking violates encapsulation of synchronization policy.
now can you help me
and what is this
"client side locking"?