• 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

question the lock() and unlock()

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,everyone :
my lockRecord() and unlockRecord() is implemented follow:

Is thread safe for the codes?
if no,which is modify for the lockRecord() and unlockRecord()?
[ December 10, 2003: Message edited by: 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 Jofer,
Please do not post your entire locking solution. Locking is worth 20% of the assignment, and so each person should work on it on their own. If another candidate could just copy your entire solution, then they have just gained a lot of marks without doing any work. This just lowers the value of the certification.
I have therefore removed the unlock() method from your posted code. Most people can see where you are going from the lock() method alone, but anyone trying to copy your code would still have to work out how to implement the unlock() method themselves - it is not difficult, but they would have to have some idea of what they were doing.
As for your code: this should be thread safe, as long as you only have one instance of lockMap for your application.
Please note that swallowing the InterruptedException is a really bad idea - you should never just hide an exception in this way. If you have code like that in your submitted application you could easily loose marks for it.
Doesn't your lock method have to throw some exceptions?
Regards, Andrew
 
Jofer Chan
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,Andrew
thank you,
I regret to give all codes for the lock/unlock.
you are right!
I should be shrow the exception in the InterruptedException block,
what's exception should be throw?
thank you.
[ December 10, 2003: Message edited by: Jofer Chan ]
 
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 Jofer,
If you search in this forum for InterruptedException you will find a lot of discussion on it.
Possibly the best solution is to create your own subclass of RuntimeException, and wrap the InterruptedException in that. This way you do not need to declare it (which would break the method signatures).
Regards, Andrew
 
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jofer,
Also it is a good idea to add check for the validity of the record.
For ex:
If record is < 0 or > than the highest number present in the DB.
Also even if the record is present it is good to check if it is deleted or not. These checks can be added before wait().
This will help the thread to get out of this method quickly.
Also it is good to check if record is deleted or not just before actually locking it. This help in the following scenario
1. Thread A has lock to delete the record
2. Thread B is waiting for the lock
3. Thread A deletes the record and unlocks it.
4. Now thread B can lock the record, but it should not as the record is now deleted.
I guess this will help to reduce lot of deadlock situations too.
Just a thought.
Manoj
reply
    Bookmark Topic Watch Topic
  • New Topic