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

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]
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, and is
believed to be clean.