Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Extending class to add another atomic operation  RSS feed

 
praveen kumaar
Ranch Hand
Posts: 450
22
Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can anyone explain me how does extending a class to add a atomic operation makes it fragile as well as client side locking makes it more fragile?
 
praveen kumaar
Ranch Hand
Posts: 450
22
Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i read it in "threads in practice" by brian goetz,... in section 4.4.1
 
Stephan van Hulst
Saloon Keeper
Posts: 6967
109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I don't really have the context of the discussion, so I can only venture a guess.

It sounds like these actions give the client a false sense of security: Adding an atomic operation to a class does not make the class thread-safe. It's best to make the class fully thread-safe, or leave the entire responsibility to the client.

For the bit about client side locking I would need an example to know what the author was talking about.
 
praveen kumaar
Ranch Hand
Posts: 450
22
Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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"?
 
Stephan van Hulst
Saloon Keeper
Posts: 6967
109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I updated your post to format the code, it's more readable now.

In this example, client-side locking refers to the fact that for the client to interact with the list correctly, the client has to lock on the list:

Here, the responsibility to lock on the list lies with the clients of the list. This is BAD. It's very fragile, because all clients have to promise to do this, and it's easy to forget or get wrong.

Instead, list should have been a private field, and the helper class should provide all methods to interact with the list in a thread-safe way.
 
praveen kumaar
Ranch Hand
Posts: 450
22
Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks stephan.
so client side locking is actually providing locking code by client during the implementation of a class in order to meet condition on invariants 
or to maintain atomicity(precisely,thread safety).isn't it?
 
Stephan van Hulst
Saloon Keeper
Posts: 6967
109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The issue here is that thread-safety is something a class should achieve by itself, or not at all. The responsibility should not be shared.

A class is thread-safe or it's not. ListHelper is not thread-safe, no matter how you look at it. I can easily break it by acquiring a lock on list without ever releasing it. Any other clients of ListHelper will deadlock.

If the goal of putIfAbsent() is to avoid duplicate entries, I can break that simply by adding a duplicate to the list directly.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!