• 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

URLyBird avoiding deadlock the simple way?

 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone,

I am trying to come up with a simple system to avoid deadlock in my application. I have exposed the lock and unlock methods to the client and have coded my server so as to use appropriate locking on the records themselves. I have read on previous posts that provided I can guarantee that each client can only own one record lock at a time there would be no possibility of deadlock.

The solution I propose is to create a mutex in each client that must be locked before a client attempts to lock a record on the server side. My thinking is that if a client has to wait for a record lock from the server, the fact that I have obtained the client-side mutex lock will prevent the client from attempting to get another lock until the record lock is gained and the mutex released (although if I never get the record lock there might be a problem )

Does anyone have any comments on this strategy (or am I missing anything obvious)? Many thanks
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, limiting each client to 1 lock would prevent deadlock.

Even if you limit each client to 1 lock each, you will still some sort of timeout to prevent an inconsiderate client from hogging a record forever.
The timeout will resolve any deadlocks anyway so you don't really gain anything from limiting to 1 lock each (and you might get an automatic failure).
 
Daniel Bryant
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Roy,

Many thanks for your input. I've read many previous posts that suggest using a timeout in the URLyBird assignment is not necessary (and may even go against the supplied requirements) and so I was trying to avoid this approach.

You make a good point about automatic failure - I hadn't considered if Sun will test my implementation of their interface with a fair client (by my definition capable of holding only one lock).

I will have to give this some thought - I could go with it and include it in my javadoc/choices.txt, but it may not be worth the risk.

Many thanks,

Daniel
 
Eliminate 95% of the weeds in your lawn by mowing 3 inches or higher. Then plant tiny ads:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic