Threading problem (incredibly straightforward mutex usage not working)

[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.Wa itOne();
if (previewerThrea d != null && previewerThread .IsAlive)
{
evl.WriteEntry( "WaitingForPrev iewerThread");
previewerThread .Join();
evl.WriteEntry( "FinishedWaitin g");
}
DocSearch.previ ewSource = source;
DocSearch.previ ewTarget = target;
previewerThread = new Thread (DocSearch.prev iewStarter);
previewerThread .Priority = ThreadPriority. Normal;
previewerThread .Name = "PreviewDownloa der";

previewerThread .Start();
previewMutex.Re leaseMutex();
}
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 WaitingForPrevi ewerThread 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 backgroundPrevi ew()
{
try
{
Common.GetFile( DocSearch.previ ewSource,DocSea rch.previewTarg et);

Common.SendMess age (Common.mainHwn d, Common.WM_PREVI EWREADY, 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
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tyler Sample]

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( "WaitingForPrev iewerThread\r\n "+AppDomain.Get CurrentThrea
dId().ToString( ));
previewerThread .Join();
evl.WriteEntry( "FinishedWaitin g");

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 WaitForSingleOb ject(threadHand le) 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...

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tyler Sample]

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/archiv.../02/66219.aspx

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!