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

>From: "Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>

>However, the "get all the keys and then suspend"
>means that a process could continue to grab keys with
>(theoretically) in a suspended state.

Which is only an issue if you consider the grabbing of keys to
be an action of the suspended process. The LRM does not say
which process is performing that action. You could assume that
it is done by the semaphore itself (i.e. some separate arbitration
process that is associated with the semaphore, independent of its
callers). That seems like an unlikely way to implement it, but
there is nothing wrong with it conceptually.

A more likely way of implementing it would be for the process
executing put() to perform this action. After adding its keys
back, it could check to see if there was a process at the front
of the queue whose request was now satisfied. If so, it could
subtract the request, remove the process from the queue, and
schedule it to execute. It would repeat until the request at
the front of the queue could not be satisfied. Then it would
return from the put().

This would be a perfectly reasonable way to implement it, and it
does not require a waiting suspended process to take any action
to "grab" its keys. The live put-ting process would take the
action. The suspended process would remain passive. Its keys
would be allocated to it, and it would be off of the queue, but
it would wait for a resume before executing again.

>That seems to at least
>suggest a clarification about what happens during a suspend
>(and perhaps a kill) in such scenarios.

I definitely agree that a clarification is called for. While
I think this #3 option is the cleanest solution, I don't think
the LRM specifies it.

Another advantage of #3 is that the other options would require
us to make further decisions about where in the queue the process
would go when it resumed :-)

But here is some input on that decision, in case we go that way.
One thing to note is that the rule needs to apply to the general
case, where the process could be anywhere in the queue. A rule
of resuming at the back of the queue seems reasonable, regardless
of where the process was when it was suspended.

A simple rule of resuming at the front does not seem reasonable,
since it could result in the process skipping forward as a result
of being suspended and resumed. So scheduling at the front in
your described case would have to be the result of a more general
rule being applied when the process was already at the front. It
would have to involve some form of "holding current position". I
can see a couple of possible forms of that. One would be to note
the number of processes ahead of it when it suspended, and to resume
it at that same position (or at the end if there were fewer than that
in the queue). Sort of like falling asleep in line while others
sneak past you, and then waking up at the same physical position,
and possibly noticing that you needed to advance to the end of
the line.

The other would be for the process to remain in the queue, moving
forward normally as other processes were removed. When it reached
the front of the queue, it would remain there, and any processes
behind it could bypass it to take keys. It would behave as if it
were not in the queue, except for purposes of keeping track of how
far it would have progressed if it had stayed in the queue. This
would be as FIFO as possible without actually taking any keys.

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.