🚀 go-pugleaf

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:kcaqe3d7a9ahqkl01dpp52rerc4g54o9et@4ax.com...
>
> Mutexes are "owned"
> Your thread 1 owns the mutext (created with True)
>
> Thread 2 Opens and attempts to Release the Mutex.
> It fails to do so because it does not own the mutex.
> Thread 2 doesn't even attempt to own the mutex.
>
> Meanwhile, thread 1 issues a WaitFor on the mutex it
> already owns, which succeeds instantly.
>
> Semaphores don't have "owners", just "state"

To expand upon what Bob said, Semaphores are typically used to 
synchronize/serialize access to a limited number of resources as they have a 
count value associated with them.  They can be used for thread 
synchronization if the maximum count is set to 1, but they are a pretty 
expensive way (in terms of CPU cycles) to do simple thread synchronization.

Mutexes are typically used to synchronize access between processes,  as 
their handle can be shared with other processes in the system.  However, Bob 
is incorrect in his analysis of the mutex problem you are having. First, it 
is true that mutexes are owned, but they are not owned by threads -- they 
are owned by the process.  Second, your mutex is created in the signalled 
state, so the first thread that tries to wait on it (thread #1 in this 
case), will immediately succeed.  In your sample code, thread #2 never tries 
to wait on the mutex, and immediately releases the mutex (which has no 
effect because it is already in a signalled state, but not because it 
doesn't own it).  The order in which the threads execute, in this case, 
makes no difference because the mutex was created in the signalled state 
(unless there is code missing from your example, which is highly likely, 
from what I can tell).

If you change your code to create the mutex in the non-signalled state, you 
could see different behavior.  In this case, the order in which the calls 
occur will affect the outcome.  If thread #2 releases the mutex (setting it 
to the signalled state) before thread #1 tries to wait, then thread #1 will 
immediately succeed when it calls the wait function.  However, if thread #1 
attempts to wait on the mutex before thread #2 releases the mutex, then it 
will wait until the mutex is released, which in your code is almost 
immediate.

So, both mutexes and semaphores can be used to synchronize threads.  But a 
more efficient way to synchronize threads is to use critical sections. 
Critical sections are the simplest and most efficient synchronization 
mechanism -- they cannot be shared across processes like mutexes, and don't 
have a count associated with them like sempahores.

Based on your code (which I presume is only an example), I am not sure what 
it is you are trying to accomplish with synchronization, so it's impossible 
to suggest which synchronization mechanism is best for your application. 
For fast, simple synchronization, use a crticial section.  To synchronize 
threads across process boundaries, use mutexes.  To synchronize access to 
limited resources, use a semaphore.

There are also events (manual- and auto-reset), which have a slightly 
different purpose, but I doubt they would be useful in your current 
situation.

I highly recommend the book, "Advanced Windows" (practially any edition) by 
Jeffrey Richter.  He discusses, in sufficient detail, how all of the 
different synchronization mechanisms work, and gives very good examples of 
their use.

- Dennis