• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Extending class to add another atomic operation

 
Ranch Hand
Posts: 491
23
Eclipse IDE Firefox Browser Spring VI Editor AngularJS Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 491
23
Eclipse IDE Firefox Browser Spring VI Editor AngularJS Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i read it in "threads in practice" by brian goetz,... in section 4.4.1
 
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 491
23
Eclipse IDE Firefox Browser Spring VI Editor AngularJS Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 491
23
Eclipse IDE Firefox Browser Spring VI Editor AngularJS Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
And when my army is complete, I will rule the world! But, for now, I'm going to be happy with this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic