---how to lock two mutexes simultaneously in atomic mode?
-
mutex1 in thread 1 mutex2 in thread 2 how to lock the two mutexes simultaneously in thread 3?:confused: Vincent
-
mutex1 in thread 1 mutex2 in thread 2 how to lock the two mutexes simultaneously in thread 3?:confused: Vincent
You can't lock two mutexes simultaneously in Windows. You can only do them one at a time. Be careful with locking two mutexes at the same time, as it can easily lead to deadlocks.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
You can't lock two mutexes simultaneously in Windows. You can only do them one at a time. Be careful with locking two mutexes at the same time, as it can easily lead to deadlocks.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
I agree. The only way I see is for you to create a third mutex whick must be locked before accessing any of the other 2, and unlocked when the others are locked. If you try this then you will probably be on an even faster road to deadlock. Anyway, there may be better objects for you to use instead of mutexes if you are having such a strange necessity. Can you ellaborate a little bit? Rilhas
-
I agree. The only way I see is for you to create a third mutex whick must be locked before accessing any of the other 2, and unlocked when the others are locked. If you try this then you will probably be on an even faster road to deadlock. Anyway, there may be better objects for you to use instead of mutexes if you are having such a strange necessity. Can you ellaborate a little bit? Rilhas
hi ,Ryan and Rilhas the context is producer/consumer thread1 ---------------------------------------------- p(empty) mutexRW.lock() produce(item) mutexRW.unlock() v(full) ----------------------------------------------------- thread2 ---------------------------------------------- p(full) mutexRW.lock() comsume(item) mutexRW.unlock() v(empty) ----------------------------------------------------- I need to stop thread1 and thread2 sinultaneously in thread3 to avoid deadlock at p(empty) in thread1 for buffer is full or deadlock at p(full) in thread2 for buffer is empty. and I can't use a third mutex to achieve that because a third mutex would be unefficient for producer/consumer. so give me some clues to solve this problem please. thanks :confused: Vincent -- modified at 12:48 Tuesday 2nd May, 2006
-
hi ,Ryan and Rilhas the context is producer/consumer thread1 ---------------------------------------------- p(empty) mutexRW.lock() produce(item) mutexRW.unlock() v(full) ----------------------------------------------------- thread2 ---------------------------------------------- p(full) mutexRW.lock() comsume(item) mutexRW.unlock() v(empty) ----------------------------------------------------- I need to stop thread1 and thread2 sinultaneously in thread3 to avoid deadlock at p(empty) in thread1 for buffer is full or deadlock at p(full) in thread2 for buffer is empty. and I can't use a third mutex to achieve that because a third mutex would be unefficient for producer/consumer. so give me some clues to solve this problem please. thanks :confused: Vincent -- modified at 12:48 Tuesday 2nd May, 2006
I think I don't understand your problem exactly... what are p(x) and v(x)? Why would they cause deadlocks?? Anyway, it seems to me that the most adequate object for you would be a critical section instead of a mutex. The critical section has the benefit of being somewhat more efficient than a mutex. A critical section executes and locks in about 10 cpu cycles (if available) while a mutex locks in about 600 cpu cycles. The critical sections also have a very nice property that allows the same thread to lock it more than once. In fact, after a thread grabs hold of a critical section object, it can lock it as often as requested and never be blocked. This is useful in the following example: int FuncA() { cs.Lock(); do something A cs.UnLock() } int FuncB() { cs.Lock(); do something B cs.UnLock() } int FuncC() { cs.Lock(); FuncA(); FuncB(); do something C cs.UnLock() } This property may make it easier for you to avoid deadlocks, since a critical section never locks the thread that owns it. In the example above you can export FuncA(), funcB(), and also FuncC() which uses the already protected FuncA() and FuncB(), and adds a lock of its own. As mentioned, the sequence of 3 locks and unlocks is extremelly fast. There are also some downsides to critical sections. 1) They can only be used inside the same process space, and not across processes. 2) Some users also report that critical sections do not react very well when they are destroyed if some threads are trying to lock it under Windows 95. I never had any problems. 3) They don't allow a timeout value to be specified in the 95/98/Me fmaily, and also in NT4. I hope this helps. Rilhas