Originally posted by Mehmet Ali Atlihan:
Thread A locks record 1
Thread B calls lock method on record 1 but as its locked it gives up CPU and goes to wait() state.
Thread A obtains a write lock (to provide mutual exclusion in RAF)
Thread A updates record 1
Thread A releases write lock
Thread A unlocks record 1
Thread A notifyAll()
Thread B resumes its execution..
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
Hi Mehmet,
My first thought is that one should try to avoid a locking scheme that requires obtaining multiple locks. I guess there are some problems that require a locking scheme that requires obtaining multiple locks, but is this really one of them?
I would need to know more about how these two locks work in order to make a useful comment about what may be going wrong.
So I'll ask these questions:
1) When Thread A locks record 1, what really happens? Is record 1 added to some variable that keeps track of the locked records? Or does something else happen?
2) What does it mean to say that Thread A has a lock on record 1? Is this a read-only lock?
3) When Thread A gets a write lock on record 1, what really happens? Is record 1 added to some variable that keeps track of the records that hold an active write lock? Or does something else happen?
4) What does it mean to say that Thread A has a write lock on record 1? Does this mean that no other thread can update the record?
5) Do you really need a read lock and a write lock, or is it possible to satisfy the requirements using only a single lock?
After answering these questions you might come to the conclusion that you don't need to obtain multiple locks.
If not, it's possible to figure out how to successfully prevent deadlock in a locking scheme that requires multiple locks. However, I think it's more complicated than having a locking scheme that requires only a single lock (that is a lock that's used for both reading and writing).
You raised a concern about exclusive access to the RAF. This is indeed a legitimate concern but it may be possible to enforce exclusive access in ways other than using a write lock. For instance, if you knew that you could only have a single RAF, and you synchronized on this RAF whenever you accessed it, then wouldn't you be enforcing exclusive access?
Hope this helps,
George
1) When Thread A locks record 1, what really happens? Is record 1 added to some variable that keeps track of the locked records? Or does something else happen?
2) What does it mean to say that Thread A has a lock on record 1? Is this a read-only lock?
3) When Thread A gets a write lock on record 1, what really happens? Is record 1 added to some variable that keeps track of the records that hold an active write lock? Or does something else happen?
4) What does it mean to say that Thread A has a write lock on record 1? Does this mean that no other thread can update the record?
5) Do you really need a read lock and a write lock, or is it possible to satisfy the requirements using only a single lock?
Actually that part might be the reason for this mess. My initial idea for providing the mutex in RAF was to synchronize the RAF itself as you mentioned .But after reading some messages in the forum some argue that it wont be an ideal choice to block the entire file and even when a record is locked, any read thread should read the record if its not updated yet.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
1) Thread A locks record 1
2) Thread B tries to lock record 1 but gives up CPU
3) Thread A is supposed to resume its execution but it doesnt. The program stucks
Regards, George
SCJP, SCJD, SCWCD, SCBCD
[Let me ask you this: If you run Thread A by itself (without Thread B running) does your application work the way you want?
Regards, George
SCJP, SCJD, SCWCD, SCBCD
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |