aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes What's the fuzz about synchronized(collection)? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "What Watch "What New topic
Author

What's the fuzz about synchronized(collection)?

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi all,
The more I read older postings/questions there more concerned I get...
I remember having read somewhere that the logical record locking shouldn't be implemented the straight-forward way:

That would, therefore, not be an accepted solution because the synchronized object is the collection itself instead of the key object (recNo in this case)?
Hope someone can clarify this issue.
Regards,
Marcel
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Marcel
Originally posted by Marcel St�r:
Hi all,
The more I read older postings/questions there more concerned I get...
I remember having read somewhere that the logical record locking shouldn't be implemented the straight-forward way:

That would, therefore, not be an accepted solution because the synchronized object is the collection itself instead of the key object (recNo in this case)?

I remember most people do locking in this way only. That is, lock on the collection that holds locks/cookie pairs, check if recNo is already locked, if so wait for lock to release, if not lock the record and do the operation and finally unlock. And I think they also got perfect score in locking if they do like this also. But its NOT guarenteed, though.
Doing record level locking, i.e. synchroinizing on the particular record, check if the record is locked and waiting on the record itself instead of collection as above is a different design totally.
Good Luck.

Hope someone can clarify this issue.
Regards,
Marcel
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Marcel,
That would, therefore, not be an accepted solution because the synchronized object is the collection itself instead of the key object (recNo in this case)?

AFAIK, both solutions are accepted. And some tests of mine even show that notifyingAll() threads waiting on the locks collection may globally be more efficient (a bit surprisingly) that notifying threads waiting on locks at the record level. The only think which is often questioned in that area is the (for me useless) notifyAll() called from lock().
Regards,
Phil.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi Phil,

The only think which is often questioned in that area is the (for me useless) notifyAll() called from lock().

Why should that be useless? After all the current thread locks the recNo/cookie map..??
Regards,
Marcel
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Satish:
Doing record level locking, i.e. synchroinizing on the particular record, check if the record is locked and waiting on the record itself instead of collection as above is a different design totally.


What? I am so confused. I thought that was record level locking? What do you mean "synchroinizing on the particular record" instead of a collection?
Again another Philippe, what does AFAIK mean??


SCJP 1.4, SCJD 1.4, SCBCD (Preparing!)
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Min
Originally posted by Min Huang:
Satish:
Doing record level locking, i.e. synchroinizing on the particular record, check if the record is locked and waiting on the record itself instead of collection as above is a different design totally.


What? I am so confused. I thought that was record level locking? What do you mean "synchroinizing on the particular record" instead of a collection?

Please see below for explanation.

Again another Philippe, what does AFAIK mean??
AFAIK - As Far As I Know. If you would like to know more, you can check out this link NetLingo

Consider the following code:

My understanding is that above code is not exact record locking. Because in lock method, the client is waiting on lockedRecords hashmap. Therefore whenever any other client notifies on lockedRecords in unlock, all clients waiting on lockedRecords will wake and try to obtain lock on lockedRecords in lock method and then check if their particular record is locked or not. As you can see, though client is not sure of whether his particular record is released or not, it wakes up, checks and again waits. This is wasting CPU cycles. So record locking in my opinion is to wait on that particular record itself, and notify on the record only in unlock. This way client is notified only if the record of its interest is notified in unlock and not for any other records as the above case.
Did I help you or confused you some more? Good Luck.
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Did I help you or confused you some more? Good Luck.

Hmm. A little bit of both. Since I already wrote my locking scheme the way you mentioned above, it doesnt really matter if I'm confused or not. But for my own edification, can you give an example, in pseudocode, or record level locking?
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Marcel,
Why should that be useless? After all the current thread locks the recNo/cookie map..??

The purpose of notification in locking is to wake up waiting threads to make them able to check if the lock they are waiting for is available.
So in unlock(), a call to notifyAll() just does that. The unlocking thread tells his pals: "Hey guys, I just released a lock, maybe you're interested by that information". Useful.
But in lock(), a call to notifyAll() exactly consists in the locking thread telling his pals: "Hey guys, I just grabbed a lock. I know the information is useless for you (because you won't be able to grab the same lock anyway, as it's now mine), but I waked you up just for the fun". Not only it's useless, but it uselessly consumes CPU cycles (which goes against the instructions BTW).
Regards,
Phil.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Min,
Again another Philippe, what does AFAIK mean??

AFAIK means "As far as I know".
FYI (for you information ), here is the NET acronyms dictionary I use when I find one that I don't understand.
Regards,
Phil.
PS: Mmh... I just noticed that Satish uses the same references than I do...
[ April 13, 2004: Message edited by: Philippe Maquet ]
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi ranchers,
I'd like to comment on Satish's post. He really hits the nail on the head by expressing his concerns about the posted code. That's what I was refering to in my original post... Thanks for speaking it out loud.
The code does indeed achieve record locking in that it effectively locks/unlocks records. It does so in a very unefficient way though. If thread B trieds to lock record 5 while thread A is in the middle of locking record 3 B has to wait because A holds the mutex on the HashMap object.
My ideas/thoughts/questions to get around this deficit:
  • create a Record class with two member variables id & cookie, since one nees to sync on the individual record and not on the collection
  • have a static HashTable (because it is synchronized) with recNo/Record as key/value pairs
  • in lock method get Record from table... and then?

  • ...stuck at this point...

    Best regards,
    Marcel
    Satish Avadhanam
    Ranch Hand

    Joined: Aug 12, 2003
    Posts: 697
    Hi Marcel & Min
    Originally posted by Marcel St�r:
    Hi ranchers,
    My ideas/thoughts/questions to get around this deficit:
    1. create a Record class with two member variables id & cookie, since one nees to sync on the individual record and not on the collection
    2. have a static HashTable (because it is synchronized) with recNo/Record as key/value pairs

    You might want to think about this. If you are synchronizing access to Hashtable whereever it is used, then its not of much use to hashtable.

    3. in lock method get Record from table... and then?
    ...stuck at this point...
    Best regards,
    Marcel

    My approach was a bit different. All records present will have a flag which indicates whether record is locked. In lock method, I check this flag if its locked or not, if so wait on record, if not, lock the record by changing the flag. Also a cookie will be assigned for security reasons. There is no concept of using hashtable only for lockedRecords. In update, delete methods, this cookie is checked if record is locked by same client or not. In unlock, again synchronize on record itself, notify on record. This is how I did and it seems to be working OK.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: What's the fuzz about synchronized(collection)?