Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

locking using notify/wait

 
Tomasz Wilk
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, what do you think about below lock/unlock code? I know that solution used should not be complex, but... I think my solution would wait only on a row, not on a whole Data object...
cookies - mapa <Integer, Long>
mutexes - mapa <Integer, Object>
mutex - obiekt

public long lock(int rowNr) {


boolean isOk=false;

Long cookie = null;

synchronized(mutexes) {

mutex = mutexes.get(rowNr);

if(mutex == null) {

mutex = new Object();

}

mutexes.add(mutex);

}

synchronized(mutex)

{

while(!isOk)

{

synchronized(cookies) {

isOk = (cookies.get(rowNr) == null);

}

try

{

if(!isOk) {

mutex.wait();

}

} catch (InterruptedException e)

{

log(Level.SEVERE, "InterruptedException during lock");

//poslanie wyzej

}

cookie = generateCookie();

synchronized(cookies) {

cookies.add(cookie);

}

}

}

return cookie;

}


public void unlock(int rowNr, long cookie) {


Long cookie = null;

synchronized(cookies) {

cookie = cookies.get(rowNr);

}//sprawdzenie czy wartosc cookie jest poprawna

synchronized(mutexes) {

mutex = mutexes.get(rowNr);

}

synchronized(mutex) {

synchronized(cookies) {

cookies.remove(rowNr);

}

mutex.notify();

}

}
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Buddy, I am not very sure what you are trying to do, but I can guarantee you I did my best to try to understand your uncompilable code.

If you want a piece of advise, mine would be: try something simpler.

You say you wait on a single row, which is false, because you synchronize the access to the whole cookies collection, therefore, while you get synchronize access to this collection no other object, irrespective of the row trying to lock, will get access to it.

At any rate, and forgive my honesty, your code does not look very good to me for two very simple reasons: first, it does not even compile, and second, the idea behind it (or at least what I can understand you are trying to do), is simply too complex for the very simple task these methods are intended to do, that is, to get and release locks over a database record.

But of course, that is just my personal opinion.
 
Tomasz Wilk
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep, I admit that it is complex and probably don't compile as I just created in a text editor as a general idea.
But:
"You say you wait on a single row, which is false, because you synchronize the access to the whole cookies collection, therefore, while you get synchronize access to this collection no other object, irrespective of the row trying to lock, will get access to it."
You are correct - I am synchronizing on cookies map. But see what is happening there exactly. This synchronization is to only add/remove something from/to cookies. Should I allow multiple threads access the map concurrently? If the map is synchronized internally I would agree... but generally adding/removing elements should be synchronized. Don't you agree?

I know a very simple solution - just to make lock/unlock methods synchronized and wait/notify if a row is currently in use/not in use.
But it will not lock on a row actually. It will lock on a Data object which is... well... not optimized solution... while still being simple. Or... do you have any other solution in mind?

Regards
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The idea with the Data class is that its methods are not synchronized, precisely because it is intended for several clients to read and update records concurrently.

Therefore, the purpose of the lock mechanism is simply to require a lock to update a record before letting a thread do anything with it, but the update and delete operations should not be synchronized, as far as I understand. As for the reading operation, it does not even care about the record lock.

The lock mechanism will evidently get a lock per record, and that lock should be validated in the update and delete operations.

For instance:


This implies that, before updating a record, you would need to get a lock on it:



As you can see, all synchronization is handled in the lockRecord and unlock methods. That won't prevent the rest of the Data class methods from executing while a lock is being obtained. But of course, you will indeed require that all locks are obtained and released one by one, that's why you need a bit of synchronization here.
[ September 21, 2007: Message edited by: Edwin Dalorzo ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic