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

Any reason why I'm getting multiple copies of this message? Is it just me?

I too recall that discussion. As I recall, the original intent was for the semaphore key allocation to be atomic and the queue waiting to be ordered (FIFO). That means that a process requesting 1 key should be able to jump ahead of another process that was already waiting for 2 keys (when only one was available). I also recall that we could accommodate the two behaviors by providing an additional flag to the semaphore to ensure fairness - and force all request (as well as the queue) to be strictly FIFO.

As to the interaction between semaphore and suspend, I'm somewhat sympathetic to John's viewpoint that some things are probably best left out of the standard. I think that to be consistent with the existing verbiage of the LRM, a process waiting for a semaphore will have to be removed from the semaphore queue and then re-execute the get once it has been resumed. I'm not particularly happy about such an outcome, but I believe it would be consistent.

                Arturo

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Vreugdenhil, Gordon
Sent: Monday, July 19, 2010 7:42 PM
To: Steven Sharp; sv-ec@eda.org; sv-bc@eda.org; sharp@cadence.com
Subject: [sv-ec] 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<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.