Re: [sv-ec] RE: [sv-bc] Opinions on semaphores and suspend operations

<I forgot to copy the sv-bc on this email>

-------- Original Message --------
Subject: Re: [sv-ec] RE: [sv-bc] Opinions on semaphores and suspend operations
Date: Wed, 21 Jul 2010 14:40:32 -0700
From: Neil Korpusik <neil.korpusik@oracle.com>
Reply-To: neil.korpusik@oracle.com
To: SV_EC List <sv-ec@eda.org>
CC: jarekk@aldec.com

<forwarding bounced email from jarekk@aldec.com>

-------- Original Message --------
Subject: Re: [sv-ec] RE: [sv-bc] Opinions on semaphores and suspend operations
From: Jarek Kaczynski <jarekk@aldec.com>
To: "Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>
Cc: Steven Sharp <sharp@cadence.com>, sv-ec@eda.org, sv-bc@eda.org

Gordon,

As long as the standard keeps FIFO queue requirement in 15.3.3 (page 300),
option #3 seems the only logical behavior.
If the queue is FIFO, then it really doesn't matter if get(2) removes one
available key or waits for the availability of two keys - if the process
issuing 'get' was at the head of FIFO, no other process should be allowed to
jump ahead - even if it only needs one key.
To allow any other behavior of semaphores, FIFO rule would have to be
removed and 'queue with priorities' introduced instead. I don't think we
really want to do it - it would open real can of worms, incompatibility with
current version being the major issue.
We should not worry about suspension of the process waiting at the head of
the FIFO queue - it is well known deficiency of of semaphores (as
implemented in other languages and operating systems). Testbench or model
not taking this situation into consideration should be allowed to fail.
As Steven mentioned earlier, we do have another problem in IEEE 1800-2009:
try_get() as described in 15.3.4 is underspecified in the situation when
there are not enough keys. Current version of the standard says that the
function should return zero, but does not specify FIFO queue treatment:
should the process stay at the current queue position or be dumped out of
it? The best suggestion would be to add one more argument to the prototype,
let's say:
   function int try_get(int keyCount = 1, int quitQueue = 1 );
with assumption that failed attempt to get keys kicks the process out of the
queue for the default value of the new argument, and makes it stay in the
queue when argument is zero.

Thanks,

Jerry Kaczynski
Research Engineer
ALDEC, Inc.

On Mon, Jul 19, 2010 at 7:41 PM, Vreugdenhil, Gordon <
gordon_vreugdenhil@mentor.com> wrote:

> Right - that was part of the discussion I had with Jamie then (and
> again today). I'm not sure that I completely agree that suspend
> couldn't be "more pre-emptive" than a multi-key wait, but such
> an interpretation would break the "linearization" (the stated
> fifo behavior). However, the "get all the keys and then suspend"
> means that a process could continue to grab keys with
> (theoretically) in a suspended state. That seems to at least
> suggest a clarification about what happens during a suspend
> (and perhaps a kill) in such scenarios.
>
> Gord.
>
>
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com <sharp@cadence.com>]
> Sent: Mon 7/19/2010 6:05 PM
> To: sv-ec@eda.org; sv-bc@eda.org; Vreugdenhil, Gordon; sharp@cadence.com
> Subject: Re: [sv-bc] Opinions on semaphores and suspend operations
>
> OK, I found the other discussion that I was remembering. There were a
> couple of differences from what I remembered. One of them is that I did
> not initiate it. I thought that I did, because I had run into the issue
> before Jamie brought it up. The other is that it focused on whether a
> get(1) could bypass a waiting get(2) when there was 1 key available,
> and try_get() was only mentioned in passing. See
>
> http://www.eda-stds.org/sv-ec/hm/2651.html
>
> But most of the discussion seemed to be assuming that the single key was
> not taken by the get(2), and was still available for the get(1). The
> only question was whether the get(1) could bypass the queue and take it.
> If the get(2) was considered to be holding the single key already, then
> it would not be available. The issue of bypassing the queue would not
> come up (unless you wanted to allow races where the get(1) could grab the
> key only if a put happened at the same time as the get(1), and the get(1)
> happened to execute before the process at the front of the queue grabbed
> it).
>
> Overall, the viewpoint seemed to be that the keys were not taken until
> the entire request could be granted. That would eliminate option 1 in
> the suspend situation, since no partial requests would be held.
>
>
> Steven Sharp | Architect | Cadence
>
> P: 508.459.1436 M: 774.535.4149 www.cadence.com
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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