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

Hi All.

I don't think this should be a language issue, unless it can be
included in the Std independent of whether there is a block
during operation or not.

By analogy, synthesizable SV forbids assigning the same variable
in two always blocks, but SV itself allows this, even though
it risks a race condition. The language allows the writer to
take this risk. So also should it allow the writer to risk
a deadlock during operation. That's what watchdog code is
there for!

On 07/19/2010 05:25 PM, Steven Sharp wrote:
> I ran across this issue a month or so ago, and hadn't gotten around to
> bringing it up. I didn't consider the specific case of a process at
> the head of the queue with some of its requested keys available. I
> didn't consider this to be any different from the general case of being
> suspended while waiting on the semaphore.
>
> That is because I don't view the process at the head of the queue as
> having taken the initial key. It waits until there are two, and then
> takes them both. So there are none held, and none to be rescinded. So
> this "partial" situation is not special. It is the same as any other
> situation where a process is suspended while waiting in the queue.
>
> A while ago I pointed out what I considered to be an error in the LRM.
> It says that a try_get will proceed if the requested number of keys is
> available. It does not say that it proceeds if the requested number is
> available and there are no previous processes waiting on them. One way
> to view this is that if there is a process at the head of the queue,
> it is holding all of the keys that were available, so that the try_get
> cannot get them. The other way to view this is that the partial set
> of keys has not been taken, so that the try_get can grab them, bypassing
> the normal fifo order. Since I was viewing it this second way, I felt
> that this violation of fifo order was bad. But I think that Arturo or
> Dave said that it was supposed to work this way. If so, that would
> confirm the view that a process does not take the keys until its entire
> request is satisfied. I went back and did not find the discussion I
> remembered, but I see Mantis 1738 is similar. I consider this to be a
> more likely situation than the suspend, and a more important reason for
> settling whether the first process is holding those keys.
>
> So anyway, I tend to reject your option 1 as being based on an incorrect
> premise.
>
> I considered your option 2, and noted that it destroyed the fifo ordering.
>
> I saw another bad option:
>
> 4. The process is considered to do its own operations to take the keys
> and remove itself from the front of the queue. Since it is suspended,
> it cannot do this, so all processes in the queue are frozen until this
> first process can take itself off of the queue. This preserves fifo
> ordering, but locks up the queue until the process resumes.
>
> I decided that your option 3 was the right answer, since it preserves
> the fifo ordering and does not lock up the queue.
>
> I assume that when you say this is bad for resource management, you are
> referring to the fact that this process ends up holding those keys and
> making them unavailable while it is suspended. But the same is true if
> the process is suspended (or worse, killed) immediately after it gets
> the keys. If you suspend or kill processes that could hold keys, then
> you have this problem, and none of these options fix that. On the other
> hand, option 3 does ensure fifo behavior.
>
> I think we should guarantee linearization, because we can actually do
> that successfully. That should take priority over trying to keep the
> resources available, since we can't guarantee that in the general case
> anyway.
>
>
> Steven Sharp | Architect | Cadence
>
> P: 508.459.1436 M: 774.535.4149 www.cadence.com
>
>
>

-- 
         John Michael Williams
         jwill@BasicISP.net
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.