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

> even though it risks a race condition

But if you write to the variable from an always_comb, always_latch or
always_ff, then not even an old-style always block can legally write to that
same variable. A methodology that forbids old-style always blocks protects
from some race conditions.

-- Brad

On Tue, Jul 20, 2010 at 9:21 AM, John Michael Williams
<jwill@basicisp.net>wrote:

> 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.
>
>

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