Subj : Re: Hyper Threading / Multi-Threaded Queue / Application Freezes
To   : comp.programming.threads
From : ritchie.annand
Date : Wed Apr 27 2005 03:45 pm

One thing I did to suss out possible deadlocks like this was to wrap
the critical sections in a class, then have a debug version that uses
TryEnterCriticalSection in a small loop; if it didn't come back in a
reasonable time (I set mine *short* because I have an application-wide
policy of not blocking), then I make it log and blow up.

It may be something -just- outside of a critical-section-protected area
that should be inside, or you may need to put in a soft 'co-guard' in
the form of a boolean that gets set/checked inside the protected code.

I can practically *guarantee* you that it's *not* a problem with
critical sections and multithreading on HT machines. If you run on a
multi-processor/non-HT machine, the troubles should become even *more*
apparent.

Porting to Linux, in my case, made some issues even *more* apparent,
because the threading launch sequence between Windows and NT is
different (one puts the new thread into the scheduler, the other
executes the new thread almost immediately, IIRC).

Running your program on HT machines means that operations that may have
been protected by context switches (e.g. the CPU simply -can't- access
this memory from more than one spot) aren't - you have a leak at the
side of an algorithm.

I've fixed about five multi-processor-related problems, and they have
all been my fault. Very, very subtle, but always my fault. I had a
thread pool class that would miss one in 500 items queued for it - I
hadn't properly protected near an if (thread_proxy->item_assigned())
check.

Keep looking! If there are classes/functions that are a bit suspicious,
flowchart them out, and label every single thing that could be called
from single threads, *including* simple assignments (x = y; isn't
thread-safe on a multiprocessor machine - you may have to guard it or
prepare to use the Interlocked functions). Be ruthless.

Using the TryEnterCriticalSection trick should work as well - if it
deadlocks, be sure to get a stack dump or grab a breakpoint.  If you
can, swallow the exception, *don't* release the critical section, and
let the program keep going, because usually there's a *second* thread
that will give the deadlock warning, and you can find out what's
fighting.

Hope some of that rambling helps, Wal :)

-- Ritchie Annand

http://nimblebrain.net

.