Re: CMutex /CEvent (multiple threads)

Mutex: one of the threads, unknown, unpredictable, and uncontrollable, will run; the rest
will remain waiting. You cannot tell which thread, and you cannot control which thread.
But one of the waiting threads will run.

Event: For an auto-reset event, one thread, unknown, unpredictable, and uncontrollable,
will run; the rest will remain waiting. You cannot tell which thread, and you cannot
control which thread. But one of the waiting threads will run.

Event: For a manual-reset event, all threads will run. No subsequent WaitFor... will
block until the event is reset and the event in question is the critical handle that will
cause the WaitFor... to block.

Note: NEVER confuse the behavior of a mutex and an autoreset event. A mutex guarantees
that no more than one thread will run until the mutex is released, and the mutex can only
be released by the thread that owns it. Mutexes have recusive acquistion semantics,
meaning that a thread which owns the mutex will not block on a subsequent attempt at
acquisition. Events do not possess any of these properties. I find it unfortunate that a
lot of programmers seem to confuse the two (it typically takes me less than five minutes
to demonstrate the synchronization error in such cases).

CMutex is flawed beyond recovery and cannot be used in a realistic program (any code that
converts "unrecoverable synchronization error" to "successful acquisition of lock" is not
worthy of discussion of the depths of stupidity of the person who wrote the code. For a
CMutex, WAIT_ABANDONED status is explictly converted to "successful acquisition"; yoiu can
see the code for yourself)
                    joe

On Tue, 22 Sep 2009 08:24:58 -0700 (PDT), Frank <jerk@gmx.de> wrote:


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm