Threading problem (incredibly straightforward mutex usage not working)

  • Thread starter Thread starter Tyler Sample
  • Start date Start date
T

Tyler Sample

I've been having strange thread conflicts, and after moving the relevant
mutex higher and higher I've finally determined that the mutex doesn't
seem to be working at all.

Here is the relevant code:

private static Mutex previewMutex = new Mutex();

private static void preview (string source, string target)
{
try
{
previewMutex.WaitOne();
if (previewerThread != null && previewerThread.IsAlive)
{
evl.WriteEntry("WaitingForPreviewerThread");
previewerThread.Join();
evl.WriteEntry("FinishedWaiting");
}
DocSearch.previewSource = source;
DocSearch.previewTarget = target;
previewerThread = new Thread (DocSearch.previewStarter);
previewerThread.Priority = ThreadPriority.Normal;
previewerThread.Name = "PreviewDownloader";

previewerThread.Start();
previewMutex.ReleaseMutex();
}
catch(Exception err)
{
evl.WriteEntry(err.ToString());
}
}


What's happening is the mutex is not blocking properly. I look in the
event log and see the WaitingForPreviewerThread message three times in a
row, with no messages at all in between. I've verified that log message
isn't anywhere else in the code and this is the only place previewMutex
is used. The really messed up thing is that this function is only
called from a GUI event handler (OnChange event for a ListView). From
my understanding from doing MFC and Win32 programming, the GUI should
only have one active thread by default anyway, meaning this shouldn't be
possible regardless of the mutex. The code works as expected if the
user slowly arrows through the listbox including all the expected event
log messages.

Here's what the thread does, if it matters:

public static void backgroundPreview()
{
try
{
Common.GetFile(DocSearch.previewSource,DocSearch.previewTarget);

Common.SendMessage (Common.mainHwnd, Common.WM_PREVIEWREADY, 0, 0);
}
catch (Exception err)
{
evl.WriteEntry(err.ToString());
}
}

GetFile calls a web service and downloads a file. SendMessage is the
win32 API.
The handler for WM_PREVIEW is in the same form class that activates the
thread, and it displays a picture in an activeX control.

Any help is greatly appreciated!

Tyler
 
The Mutex.WaitOne will not block if no other thread has acquired the mutex. You don't show any other thread attempting to acquire the mutex. What behavior were you expecting from the Mutex?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

I've been having strange thread conflicts, and after moving the relevant
mutex higher and higher I've finally determined that the mutex doesn't
seem to be working at all.

<snip>
 
Somehow preview() is being entered two to three times without exiting
before the Join() blocks and locks up the whole application.

I'll try to do a sample application that demonstrates the problem..
 
Okay, I was unable to reproduce the problem in a simple application (big
surprise, right?)

The test application did seem to confirm my suspicion that the normal
behavior of the application is one thread per GUI. Debugging the
problem application SEEMS to confirm this (can't figure out how to
programmatically determine a thread's unique ID, though, so I'm not
sure)

What I'm ending up with is TWO messages, back to back in the event log
saying:
WaitingForPreviewerThread
GUI

Can everyone plainly see how this shouldn't be possible? The code is
failing to execute the "FinishedWaiting" log entry and is somehow
disappearing into thin air (apparently releasing the mutex on its way
out). There's only one line of code between those two log entries!
WriteEntry throws exceptions when it fails.

Is it possible a control I'm using is hosing the code stack?
I really can't even imagine where to begin solving this problem, and I
must.

The other possibility is that I somehow am ending up with two GUI
threads provided by the system for a very short period of time, but that
seems less likely than hosed memory.

//This is part of the handler for an OnChange event:
private static void preview (string source, string target)
{
try
{
previewMutex.WaitOne();
if (previewerThread != null && previewerThread.IsAlive)
{

evl.WriteEntry("WaitingForPreviewerThread\r\n"+Thread.CurrentThread.Name
);
previewerThread.Join();
evl.WriteEntry("FinishedWaiting");
}
DocSearch.previewSource = source;
DocSearch.previewTarget = target;
previewerThread = new Thread (DocSearch.previewStarter);
previewerThread.Priority = ThreadPriority.Normal;
previewerThread.Name = "PreviewDownloader";
previewerThread.Start();
previewMutex.ReleaseMutex();
}
catch(Exception err)
{
evl.WriteEntry(err.ToString());
}

}
 
Two things:

You must not use GUI elements from any thread other than the one that created them. I'm not sure whether thats what you mean by "normal behavior being one thread per GUI".

You can get hold of the thread id using AppDomain.GetCurrentThreadId();

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Okay, I was unable to reproduce the problem in a simple application (big
surprise, right?)

The test application did seem to confirm my suspicion that the normal
behavior of the application is one thread per GUI. Debugging the
problem application SEEMS to confirm this (can't figure out how to
programmatically determine a thread's unique ID, though, so I'm not
sure)

What I'm ending up with is TWO messages, back to back in the event log
saying:
WaitingForPreviewerThread
GUI

Can everyone plainly see how this shouldn't be possible? The code is
failing to execute the "FinishedWaiting" log entry and is somehow
disappearing into thin air (apparently releasing the mutex on its way
out). There's only one line of code between those two log entries!
WriteEntry throws exceptions when it fails.

Is it possible a control I'm using is hosing the code stack?
I really can't even imagine where to begin solving this problem, and I
must.

The other possibility is that I somehow am ending up with two GUI
threads provided by the system for a very short period of time, but that
seems less likely than hosed memory.
 
Well, I meant that unless I specifically do GUI stuff in one of my
threads, I have only one thread that should handle user messages
(events, mouse moves, etc..)

Thanks for the tip on the thread id. It is the same thread. It's the
same thread somehow never completing the function, so I guess this isn't
a threading problem.

Damn...Now I just have no idea where to even start. I guess I eliminate
the unsafe ActiveX controls one by one and see if that helps...

Uggh.

Well, thanks for the help!
 
Do you you DoEvents in your code? This can cause re-entrancy

Also, if you call an MTA based COM component from an STA thread you can get re-entrancy

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Well, I meant that unless I specifically do GUI stuff in one of my
threads, I have only one thread that should handle user messages
(events, mouse moves, etc..)

Thanks for the tip on the thread id. It is the same thread. It's the
same thread somehow never completing the function, so I guess this isn't
a threading problem.

Damn...Now I just have no idea where to even start. I guess I eliminate
the unsafe ActiveX controls one by one and see if that helps...

Uggh.

Well, thanks for the help!
 
No DoEvents. Not really sure about the MTA com components. That's
pretty possible. Although they certainly aren't called between the two
logging functions (one of which isn't firing). Also, wouldn't the mutex
keep that kind of expected/normal re-entrancy from happening? Somehow
that mutex is getting released, or there is a bug in the mutex class
itself, which I find unlikely.
 
The mutex won't prevent this as its thread sensitive. As its the same thread re-entering it will just aquire a second lock on the mutex

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

No DoEvents. Not really sure about the MTA com components. That's
pretty possible. Although they certainly aren't called between the two
logging functions (one of which isn't firing). Also, wouldn't the mutex
keep that kind of expected/normal re-entrancy from happening? Somehow
that mutex is getting released, or there is a bug in the mutex class
itself, which I find unlikely.
 
Oh yeah...That's true! So, I guess that leaves me some hope that
everything is working okay, although...

I'm a little vague on how I could have a legitimate re-entrancy problem
in the same thread between these lines of code:

evl.WriteEntry("WaitingForPreviewerThread\r\n"+AppDomain.GetCurrentThrea
dId().ToString());
previewerThread.Join();
evl.WriteEntry("FinishedWaiting");

It doesn't really seem that there's any way for the thread to escape
there, not matter what I may be doing elsewhere..I could certainly see
how a *different* thread could enter again...but the same one? None of
these calls are wrapped. They are straight system calls..No opportunity
to re-enter the message loop as far as I can tell! I'm catching
exceptions and logging them, and there aren't any, so....

If I'm incorrect there, I would love to read a technical article
explaining my mistake.

Also, does Join() work like a WaitForSingleObject(threadHandle) call did
in C++? Or is there some deviousness possible in that call?

Thanks for all the help so far. I'm definitely much closer to solving
this problem than before...
 
Okay, I found the problem. This was referred to earlier, but I assumed
it mentioned as deliberate behavior on the part of the controls I was
calling. I didn't realize that Microsoft built in message pumping to
their blocking calls. I'm particularly thrilled that they didn't
document it at all! Wow. I'm ALMOST speechless :) Great. Now I have
to synchronize my main application thread with itself. I see why they
did it, but I have no idea why it's not clearly documented in the
relevant function calls.

http://blogs.msdn.com/cbrumme/archive/2004/02/02/66219.aspx
 
Back
Top