It seems the same semaphoer duals as both an event semaphore and a mutex
semaphore. The problem is that according to my docs, DosSemClear() has two
roles. One is to release ownership given from a successful call to
DosSemRequest(), and two is that it clears the signal state of a semaphore
(a call DosSemWait() will then block.)
My question is how the heck does OS/2 know what the role is when
DosSemClear() is called?
Or are my assumptions incorrect?
Any help would be greatly appreciated.
Best,
Mark
Mark Graybill wrote:
> I'm porting 16-bit semaphore calls to 32-bit, but I run into a question.
>
> It seems the same semaphoer duals as both an event semaphore and a mutex
> semaphore. The problem is that according to my docs, DosSemClear() has two
> roles. One is to release ownership given from a successful call to
> DosSemRequest(), and two is that it clears the signal state of a semaphore
> (a call DosSemWait() will then block.)
No, when a semaphore is in the cleared state it is unowned and threads will not
block on it if they issue DosSemWait.
> My question is how the heck does OS/2 know what the role is when
> DosSemClear() is called?
Depends on how a thread blocked (requested ownership) on the semaphore. If
the thread is blocked on a DosSemRequest call then it is treated as a mutex
semaphore. If the semaphore is blocked on a DosSemWait or DosSemSetWait call
then it is treated as an event semaphore. The biggest difference between the
two is that when a thread wakes up from DosSemRequest it has ownership of the
semaphore, whereas when a thread wakes up from DosSemWait it does not.