This situation may be likened to two people who are drawing diagrams, with only one pencil and one ruler between them. If one person takes the pencil and the other takes the ruler, a deadlock occurs when the person with the pencil needs the ruler and the person with the ruler needs the pencil to finish his work with the ruler. Neither request can be satisfied, so a deadlock occurs.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Jeff Philp wrote:I suppose you might be referring to the thread I started here
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:
Well your thread sparked my thinking Jeff. But people seem to consistently use the term deadlock on the forum when describing this scenario. So I was puzzled, because it doesn't seem like deadlock is possible to me, so maybe I was missing something .
Jeff Philp wrote:technically (in the simple example I proposed) client A is stuck on itself, and it just means that client B is stuck waiting for the Client A to release the lock which will never happen. Client A isn't waiting on client B to release a lock.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs wrote:You could have this little scenario:
- clientA locks record 1
- clientB locks record 2
- clientA decides to lock record 2 (and is moved to waiting state)
- clientB decides to lock record 1 (and is moved to waiting state)
That's a deadlock to me, because 2 threads are waiting on each other.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:That's a totally different scenario.
Sean Keane wrote:it's not deadlock either
Sean Keane wrote:I'm talking about multiple calls by a client to the lock method on the same record
Matthew Brown wrote:I don't think the term used particularly matters. It might not be a strict deadlock,
Matthew Brown wrote:
Either way, it's a potential problem. I've not read all the previous threads on this, so you've probably discussed this already, but I think you've got three general approaches.
- Ignore it. Calling lock twice is an error - let the calling code worry about the fact that it will freeze up.
- Write the lock method so that it throws an exception if the same thread tries to get a lock it already owns
- Write the lock method so that if a thread tries to get a lock it already owns it just returns immediately
I went for option 2.
Roel De Nijs wrote:In my opinion that scenario causes a deadlock, because 2 threads are waiting for each other (to finish) and thus will keep waiting forever.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Did your lock method return a cookie? How did you go about implementing option (2) ?
Matthew Brown wrote:
Sean Keane wrote:Did your lock method return a cookie? How did you go about implementing option (2) ?
Yes, mine returned a cookie.
My lock mechanism involved creating a lock object (stored in a suitable collection). So I could use that to encapsulate whatever was necessary - in this case a reference to the owning Thread as well as the cookie.
(I also rather gratuitously used it to implement a timeout mechanism, but that's really not necessary)
Sean Keane wrote:But this is not deadlock. Deadlock is a completely different problem.
Roel De Nijs wrote:
Sean Keane wrote:But this is not deadlock. Deadlock is a completely different problem.
That all depends on the definition you have for a deadlock.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:So you mapped a record number to a lock object? Where the lock object contain the owning thread and the cookie, which were two different values?
Sean Keane wrote:Did you use RMI? If so, how did you identify the owning thread inside of your lock-method?
Matthew Brown wrote:
Sean Keane wrote:So you mapped a record number to a lock object? Where the lock object contain the owning thread and the cookie, which were two different values?
That's right.
Matthew Brown wrote:I used RMI, but I was using a thin client. All the relevant lock/process/unlock calls were in a single method of my service interface, so the networking was irrelevant.
Sean Keane wrote:I referenced the commonly understood definition of deadlock in concurrent programming
Roel De Nijs wrote:I didn't use the RMI Factory, but I would think you expose a unique instance of your business service to each client. Why would you expose your Data class if you have a business service
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Does that not make your cookie value redundant?
Sean Keane wrote:I took a quick read of the RMI Factory solution (need to look into more). But from what I could gather, you send back a separate instance of the Data class for every client? Is this correct? Which means I would have to not use the singleton. And I'm not quite sure how this will fit with my Business Service. Hmmm...
Roel De Nijs wrote:
Sean Keane wrote:I referenced the commonly understood definition of deadlock in concurrent programming
I just referenced to the general definition of a deadlock (see the link in your 1st post)
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Yep, and I can't see anything on that page that contradicts my understanding and the description I gave of deadlock in concurrent programming.
Sean Keane wrote:Neither can I see anything that supports calling the scenarios we are talking about here as deadlock. Your system has no dependency between the two resources (rooms\records) to carry out an operation. All you are seeing here is your programming waiting...because that's how locking works. You can carry out the operations of both clients at any point and unlock if you so wish.
- clientA locks record 1
- clientB locks record 2
- clientA decides to lock record 2 (and is moved to waiting state)
- clientB decides to lock record 1 (and is moved to waiting state)
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:I resolved this not by any strategy to resolve deadlock, but by simply implementing it correctly
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Alex Iordanoglou wrote:Hi Sean,
Just a tiny bit of clarification - confirmation: in your first post, in cases 2) and 5), instead of Client-A, did you really mean to say Client-B?
(Because if not, Client-A would be waiting forever upon himself to finish - release the lock as stated previously etc ect...)
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |