Locking question

[Guest]

I have a function that can be called from multiple threads that sets some
static variables. To keep things consistent I am trying to use a lock
statement. Somehow two different threads are able to get inside the lock
statement at once. Here is the code

static object checkAndWaitLockObject = new object();
private static System.Threading.ManualResetEvent mre = new
System.Threading.ManualResetEvent(true);
private volatile static int threadID;

private void CheckAndWait()
{
lock(checkAndWaitLockObject)
{
if(!context.IsTransactionPending)
{
mre.Reset();
threadID = System.Threading.Thread.CurrentThread.GetHashCode();
return;
}
else
{
if(threadID == System.Threading.Thread.CurrentThread.GetHashCode())
{
return;
}

mre.WaitOne();
mre.Reset();
}
}
}

If anyone has any ideas why the lock isn't working it would be appreciated.
Thanks, Scott

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Scott,

What actually happen? How do you know that two threads enter the lock?

 

[Jon Skeet [C# MVP]]

I have a function that can be called from multiple threads that sets some
static variables. To keep things consistent I am trying to use a lock
statement. Somehow two different threads are able to get inside the lock
statement at once. Here is the code

What evidence do you have that multiple threads are getting inside the
lock at the same time? I can't see how they would do so.

Do you have a short but complete program which demonstrates the
problem?

Jon

 

[Guest]

I'm debugging in Visual Studio. In one thread I'm on the threadID =
GetHashCode and on the other I'm on the if(!context.IsTransactionPending).
One time before that both threads said they were on the
if(!context.IsTransactionPending) at the same time. I'm hoping that the
debugger is wrong.

 

[Nicholas Paldino [.NET/C# MVP]]

Scott,

I actually think that this code is going to block if the other threads
are making calls to it. Based on what you posted, the method is
sufficiently synchronized.

However, I think you will have a deadlock at some point if one thread
gets to the point where you are waiting for an event. Using events and
other synchronization objects inside of another sycnchronization object is a
disaster waiting to happen.

 

[Guest]

I only want one instance of this class created at any time. The
manualResetEvent is fired any time the class is committed, rolled back, or
disposed. In the destructor there is a Debug.Assert to confirm that one of
those three methods have been called so there shouldn't be any deadlocks.

 

[Adam Clauss]

Actually I've seen that before and I believe it's a "oops" in the debugger.
It seems when debugging lock statements, while the thread is "waiting" on
the lock, the debugger actually highlights the NEXT line (it highlights the
line that executes next - not the current line).