RE: sc_semaphore

John,

Had to sweep away the cobwebs after all this time! Yes, I think I did propose this at one point.

Essentially what I'm proposing below is that only a process that locked a semaphore can effectively unlock it (i.e. post to it). If a process did not lock a semanphore but randomly posts to it, then the semaphore state is not changed.

The current behavior is that any post() will increment the semaphore value and unlock it - so you can have the sitn. that process A locks a semaphore and process B unlocks it maybe by mistake. This appears o be a bug?

The change that I propose does seem like an improvement. What do people think?

-Bishnupriya

________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, November 24, 2010 7:50 PM
To: Bishnupriya Bhattacharya; dcblack@xtreme-eda.com
Cc: systemc-p1666-technical@eda.org
Subject: sc_semaphore

Bishnupriya,

I believe it might have been you who wrote the following, possibly (if my memory is correct) in response to some issues raised by David:

-----
The term "number of keys" should be defined upfront as the permitted number of concurrent accesses to the semaphore, specified when constructing the semaphore.

post()

If the semaphore value is equal to the number of keys (i.e. the semaphore is unlocked), member function post() shall return the value -1.

If the semaphore was not locked by the calling function (via a wait() or trywait() call), member function post() shall return the value -1.

If the semaphore was locked by the calling process, member function post shall increment the semaphore value, and return the value 0. If processes exist that are suspended and are waiting for the semaphore value to be incremented, exactly one of these processes shall be permitted to decrement the semaphore value (the choice of process instance being nondeterministic) while the remaining processes shall suspend again. This shall be accomplished within a single evaluation phase; that is, an implementation shall use immediate notification to signal the act incrementing the semaphore value to any waiting processes.
-----

Do you still stand by this?

Thanks,

John A

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.