Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DosSemClear

3 views
Skip to first unread message

Mark Graybill

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to
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.)

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

Dave Blaschke

unread,
Jul 10, 2000, 3:00:00 AM7/10/00
to

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.

0 new messages