• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking scheme

 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a situation where lots of other classes will be manipulating a Collection. I am wondering which of these two locking schemes you thing is preferred in an OO sense.

Style 1

Style 2


I prefer the 2nd approach but the problem is it does not care who locked it. It will let anybody unlock it. plus you can forget to unlock it. I can record which thread locked it and assert if its not the same as the one that unlocked it. However, the first approach seems not so OO in design, but its simple and foolproof AFAICT.

Are there other resource locking schemes?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I must be missing something: why don't you simply make add() synchronized???
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
I must be missing something: why don't you simply make add() synchronized???


I don't use synchronized methods because I don't like to expose the monitor. That is why I have the two alternate methods. Of the two, style 1 is basically like what you suggest but I don't lock on 'this' I lock on the internal object created for locking.

Furthermore, there is a class heirachy. Some methods are in the super class and some are in the sub class. Both share the same resource and so what ever lock I use in the super class I need to use in the sub class as well.

Style one seems so un-OO, yet its so easy. Tbh, I started with style 2 before I realized I could do style 1
[ September 25, 2005: Message edited by: Mr. C Lamont Gilbert ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the very first sentence of the original post gives me the most trouble. Can you make that go away?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mr. C Lamont Gilbert:
I don't use synchronized methods because I don't like to expose the monitor.


Then why not do

 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:


because the subclass does not have access to listlock in your example. The key to my situation is the subclasses and super classes all have things they need to do and they need to lock while doing them.

For you Stan lets say two (2) other classes.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How does this make you feel?

Now subclasses have well defined extension points. I have to admit it makes me feel pretty queasy. We did lots of this in PowerBuilder in the previous millenium, almost none in Java lately.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


This is what I am doing. The parent holds a resource that must be locked during use so to speak. The decendent locks it before he uses it. The other technique I used is listed in the OP and involves calling lock and unlock methods before and after the "//do stuff" parts.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just thought of another technique. Lockers can push into a stack. If you are at the top of the stack, you have the lock. If you are not, you must wait until you are before you consider yourself as having the lock. So when a locker is done with the lock, he can remove himself from the stack, and notify the other waiters. they will all wake up, or perhaps you sleep on your own lock thingy you put in the stack. that way just one can be notified.

This would work and is a more OO approach I think. But it sure is much more complicated and also has a problem with the unlocker possibly not being able to unlock since the stack is locked by another thread trying to lock. Which I can use another lock and sleep/notify to get around but it sure is getting complex. I think maybe ill just stick to passing out a ref to the lock object.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In your original post it looked like the lock-getter was used by clients of the class, which I think breaks encapsulation in a nasty way. Using it in subclasses for additional methods that need to be synchronized looks much better to me.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you need a syncobject? Can't subclass and superclass all sync on "this" ?
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
In your original post it looked like the lock-getter was used by clients of the class, which I think breaks encapsulation in a nasty way. Using it in subclasses for additional methods that need to be synchronized looks much better to me.


Its not a violation of encapsulation to expose something if its just to a child class? I thought it would be and that was why the preference for composition.

Originally posted by Stan James :

Do you need a syncobject? Can't subclass and superclass all sync on "this" ?


Are you messin' with me? Everyone here knows its my petpeeve to not lock on an exposed 'this' object since it would violate encapsulation.
[ September 29, 2005: Message edited by: Mr. C Lamont Gilbert ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Step me through how "synchronized (this)" violates encapsulation. I'm not gettin it.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Do you agree that this is bad because lockObject is publicly visible?

"this" is not encapsulated, therefore using it as a lock object puts you in a precarious position. Look at Thread.join and see how it is locking on "this" and imagine what happens if someone else is locking on Thread.this!

To be clear, join will be stuck waiting on the monitor. Furthermore, can Sun fix this goof? Nope, because the behavior is exposed and it could effect the behavior of existing programs indavertently using this behavior.
[ September 30, 2005: Message edited by: Mr. C Lamont Gilbert ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. So I like your solution of the 28th.

I think I've been living with an invalid assumption (or a convention in my own code) that everybody who locks on a monitor does so for the same reason and it's correct for them to wait in line. I have done nothing to prevent some rogue thread from grabbing a monitor for some unanticipated reason and clogging up the works. And so far it hasn't bitten me. I'm going to have to devote some more time to the risks & benefits here.
[ October 01, 2005: Message edited by: Stan James ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic