How to use lock in C#
-
I have written a multithread program using lock(this) to realize sync. I hung up the other day and i was told lock(this) is not a good way. Can anyone give me some advice and tell my why? Thank you!
-
I have written a multithread program using lock(this) to realize sync. I hung up the other day and i was told lock(this) is not a good way. Can anyone give me some advice and tell my why? Thank you!
lock(this) can bring you in a deadlock instead create a field like this: private object syncRoot = new object(); and use lock(syncRoot) [EDIT] Not static :) field will be static only for static methods
-
What was wrong with the question you posted only half an hour before? Don't spam the forum. --- b { font-weight: normal; }
-
Bob_Sun wrote:
i was told lock(this) is not a good way.
And why didnt he back up his claim? It all depends what you need lock'd, but more important where the locking takes place.
-
lock(this) can bring you in a deadlock instead create a field like this: private object syncRoot = new object(); and use lock(syncRoot) [EDIT] Not static :) field will be static only for static methods
-
Bob_Sun wrote:
I think it is better to use this thread only
I already replied in the first thread. --- b { font-weight: normal; }
Thank you very much. I have read your following reply.
Who told you that it wasn't a good way, and what was the arguments for that?
I was just told so, and I found the following forum. http://msdn.microsoft.com/msdnmag/issues/03/01/NET/[^]
Locking should of course be kept as a minimum, and to avoid deadlocks a thread should never lock more than one object at a time. Still, for sharing data between threads there is hardly any alternative.
I wrote a class for statemachine, whenever a event is dispatched, the whole statemachine should be locked in the thread. As for number of objects locked in this thread, it is always more than 2. As this is a statemachine, state changes must be sent to upper class. As the so called upper class collects messages from many child classes, messages are first enqueued before processed. So, in this thread
lock(this) // Statemachine { ... lock(this) // MessageQueue { ... } }When several events occured in different threads, I suppose all of them will be locked at the firstlock(this) // Statemachinebefore processed. Will this cause a deadlock in my program ? -
Thank you very much.
lock( a private object )was the good way introduced to avoid deadlock. But why lock(this) brings about deadlock? I want to find the case in which my program falls into a deadlock.This article seems to mention a DeadLock http://www.codeproject.com/csharp/lockmanager.asp
-
Thank you very much. I have read your following reply.
Who told you that it wasn't a good way, and what was the arguments for that?
I was just told so, and I found the following forum. http://msdn.microsoft.com/msdnmag/issues/03/01/NET/[^]
Locking should of course be kept as a minimum, and to avoid deadlocks a thread should never lock more than one object at a time. Still, for sharing data between threads there is hardly any alternative.
I wrote a class for statemachine, whenever a event is dispatched, the whole statemachine should be locked in the thread. As for number of objects locked in this thread, it is always more than 2. As this is a statemachine, state changes must be sent to upper class. As the so called upper class collects messages from many child classes, messages are first enqueued before processed. So, in this thread
lock(this) // Statemachine { ... lock(this) // MessageQueue { ... } }When several events occured in different threads, I suppose all of them will be locked at the firstlock(this) // Statemachinebefore processed. Will this cause a deadlock in my program ? -
If those are the only lock statements in the code, and they always get called in that order, it won't cause a deadlock. But if they always get called in that order, the inner lock is of no use at all. --- b { font-weight: normal; }
Guffa wrote:
If those are the only lock statements in the code, and they always get called in that order, it won't cause a deadlock. But if they always get called in that order, the inner lock is of no use at all.
First, the second
lock(this)is not necessarily called every time, but when called the order is always the same. Second, the secondlock(this)may also be called directly from other threads which have no relation to StateMachine(outside statemachine).