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

Stuart Sutherland and Don Mills also discussed this in their first Gotchas paper, in the 2006 Boston SNUG, in Section 7.3.
The key paragraph is,

"The get() method has a subtle, non-intuitive gotcha. If the number of keys requested is not
available, then the request is put into a FIFO queue and will wait until the number of keys
becomes available. If more than one process requests keys that are not available, the requests are
queued in the order received. When keys become available, the requests in the queue are serviced
in the order in which the requests were received, First In, First Out. The gotcha is that, when
get() is called (a new request), an attempt will be immediately made to retrieve the requested
keys, without first putting the request into the FIFO queue. Thus, a new request for keys can be
serviced, even if other requests are waiting in the semaphore request queue. The following
example demonstrates this gotcha."

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Steven Sharp
> Sent: Tuesday, July 20, 2010 4:05 AM
> To: sv-ec@eda.org; sv-bc@eda.org; gordonv@model.com; 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.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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