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

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

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