RE: sc_semaphore

Philip,

Thanks for reviewing. I was not aware of the behavior of POSIX semaphores. Given that precedence, the current behavior seems to be the expected/right behavior, rather than a bug as I was wondering. So, no changes to sc_semaphore then.

Thanks,
-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Friday, November 26, 2010 3:00 AM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; dcblack@xtreme-eda.com; systemc-p1666-technical@eda.org
Subject: Re: sc_semaphore

Bishnupriya, all,

I tend to see these changes NOT as an improvement, and they might even break valid use-cases of sc_semaphore.

  I agree, that in the most common use case, any 'post' without a successful 'wait' or 'trywait' before from the same process could indicate an error.

  But the current definition of sc_semaphore follows the rules of e.g.
POSIX semaphores. There, it is perfectly fine to initialise the semaphore with '0' and have a producer process doing the 'post', while a set of consumers all 'wait' on the semaphore and perform some job when unblocked. This use-case would break with the new semantics of sc_semaphore.

  It would probably useful to extend the interface of sc_semaphore to detect invalid uses in a particular scenario. But I think for this round, it may be too late. So I would vote to keep things as they are for now.

Greetings from Oldenburg,
  Philipp

On 25/11/10 11:43, Bishnupriya Bhattacharya wrote:
> 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
>
>

--
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology R&D Division Transportation * FuE-Bereich Verkehr Escherweg 2 * 26121 Oldenburg * Germany
Phone/Fax: +49-441-9722-420/282 * PGP: 0x9161A5C0 * http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.