Is it possible that this freeze is due to a screwed config file or something, completely unrelated to threads and mutexes?
After working with HEAD for a while now, I switched back to RC1-1 which I normally used for development (don't feel comfortable developing on a cvs version for some reason), and guess what....
I experienced the
Rick syndrome twice within one hour. I never had it before.
So if that was not mere coincidence, the formerly stable release caught the pestilence from the afflicted one, or it is unrelated to the actual executable... (or, I dread to think... it's been broken all the time, but nobody noticed before).
Rick:
Linux pthreads check for double locking (if requested), but Windows does not, this is explicitely documented on MSDN. So since wxWindows must take the least common denominator...
What might work for your idea, though, is something like this:
static size_t LockingThreadID;
if(lockingTID == GetThreadID())
return; // or whatever, just don't get the lock
mutex.Lock();
lockingTID = GetThreadID();
...
do something that needs to be protected ...
...
lockingTID = 0; // don't call wxYield now...
mutex.UnLock();
// now do what you want
This tampering with the thread id variable is obviously
not thread safe as such, but hey, we aren't interested in that! We are interested to prevent the
same thread from entering again. A different thread will block acquiring the lock, fair enough. And the same thread coming back through a recursive wxYield will never try to get the lock.
The only important thing is not to have anything that might call wxYield after resetting the thread id variable to zero, obviously.
