• 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

need lock() be synchronized?

 
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the Data class, the lock/unlock is unsynchronized. Why? I think when I am locking a record, no other client should be allowed to do unlock opration.
So :


Thank you for advising.
Regards
[ June 04, 2003: Message edited by: damu liu ]
[ June 04, 2003: Message edited by: damu liu ]
 
Ranch Hand
Posts: 1327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
whats the assignment you are doing
shouldnt u provide the cookie as well?
the lock and unlock methods dont need to be synchronised because what they are meant to do it provide similar functionality as synchronising a method
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi
thank you for reply!
I am doing an old version exercise.
the lock/unlock needn't synchronized, or it will be easy to get deaklock.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, what happens if two clients (two different threads) request a lock on the same record at the same time? Is there any way that the two threads might both think that they have acuired a lock? If you don't have synchronization or volatile somewhere, I can almost guarantee that the answer is yes, there's a loophole somewhere, and your code is probably not thread-safe.
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,
in fact, there is a synchronized block in my code, which synchronized with lockMap. then when a client is putting a lock into the lockMap, the other can't put a lock in. I have a new idea: it will be better if the HashMap is a threadsafe Map.
Regards,
Damu
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mmmm... it might work (depending how it's written) but it's pretty risky. For a "thread-safe Map" (returned by Collections.synchronizedMap() I assume) each individual method call is atomic, but interruptions can still occur between method calls. Consider:

Something like this might seem reasonable, but what happends if another thread puts in a value for the same key, right after the containsKey() and before the put()? Now your new put() displaces the old value, and the other thread is screwed. I prefer using an explicit synchronized block to prevent interruptions between method calls:
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by damu liu:
hi,
in fact, there is a synchronized block in my code, which synchronized with lockMap. then when a client is putting a lock into the lockMap, the other can't put a lock in. I have a new idea: it will be better if the HashMap is a threadsafe Map.
Regards,
Damu


HI Damu,
You don't need a synchronized map, because you're already in a synchronized block for that map. Correspondingly, you don't need to synchronize the lock method(and you probably shouldn't, as then you would be changing it's signature).
M
[ June 05, 2003: Message edited by: Max Habibi ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To clarify: I assumed you meant a synchronized Map instead of using a synchronized block; Max assumes you mean in addition to a synchronized block. Either way we agree - just use the synchronized block.
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, thank you for reply.
The following is a full version lock/unlock method:

Regards,
Damu
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
Can I write locking functionality like this:

This is not an actual code. After looking at "damu liu's" code, I got an idea like this. Is it OK?
Please provide your valuable comments.
[ June 05, 2003: Message edited by: S. Ganapathy ]
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi;
in unlock(), I think "if" is not a good choice, while "while" is better.
regards;
 
S. Ganapathy
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi damu liu,
I really do not know whether to provide while or if in unlock functionality. I already told, it is not an actual code. In case of lock(), providing while is a good programming practice, where as in unlock(), if is enough, I suppose.
No need to provide while in unlock(), if we provide while, how do you throw security exception, is a question!
What do you say on this?
Regards,
Ganapathy.
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi s,
I think you are right.
another thought: the synchronized code should be put outside the if block:
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that lock() needs a while() loop, and unlock() does not. Don't use containsValue() - that could find the value anywhere in the map. We want to know if the value for this key matches the supplied cookie or not. Just use lockMap.get(recordWrapper). If it's null, the record isn't currently locked at all - no need to check again.
 
S. Ganapathy
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Damu,
I noticed synchronized(lock) should be out side to if() loop. I forgot to put it properly, it is my mistake.
Thanks for your observation.
Hi Jim,
Thankyou very much. I really did not notice tha problem. Really am mistaken to use containsValue(). Thankyou very much for identifying my mistake.
Thanks a lot Jim.
Regards,
Ganapathy.
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
My lock/unlock is in Data class, so I think the lock/unlock methods should looks like this:
lock(int rcdNum, Object lockOwner)
unlock(int rcdNum, Object lockOwner)
and use the RemoteData as lockOwner.
damu
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Damu
Does this mean that you are changing the signature of lock and unlock?
Regards, Andrew
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew,
Yes, I think so. Or how can we lock the RemoteData?
I think there should be one and only one Data that operate the db.db directly. Otherwise different Data instances will read/write the db.db ignoring the "synchronized" key word. Am I right?
Thus when I want to lock/unlock a record, I can only use the RemoteData as a user identifier. I have to pass the RemoteData as a lockOnwer.
Thank you for comment,
Regards,
Damu
[ June 09, 2003: Message edited by: damu liu ]
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Damu
You have to do what is right for you. So you can ignore my alternative if you like.
I agree to having only one Data class (although I didnt do this myself - I should have).
I had locking handled in two places. The Data class was only concerned with whether a record was locked - not who had locked it. This meant that I did not have to change the signature.
The RMI lock and unlock method kept track of which records each particular connection owned. This stopped a connection from unlocking a record it hadnt locked.
The advantage to this is that tracking ownership is done at the networking interface. No matter what network interface we decide to implement (sockets, RMI, MQ...) the manner of determining the unique owner for the lock is kept at the interface. The way you do it, you would have to force all the network interfaces to use the same method of identifying owners, which could be problematic. I can expand on this if you like.
The disadvantage is that it would be harder to add deadlock handling into my code, as this would need to be done in the Data class (or better, in a lock manager), but my Data class has no idea of who owns what locks.
Regards, Andrew
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew,
Thank you very much. I will bear you comment firmly in mind.
Best Regard,
Damu
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic