[sv-bc] Opinions on semaphores and suspend operations

We've run into an interesting interaction question that turns
into a philosophical question of one's view of semaphores. I'd
like to see if anyone has opinions on this.

Imagine that you have a process (call it "A") that has done a
"get(2)" on a semaphore and blocks since only 1 key is available.
While it is blocked, some other process does a fine-grained process
"suspend" on "A". What happens?

Some options:
   1) the initial key is held; "A" suspends and when it resumes it
      waits for one more key before continuing. 2 sub-cases:
      a) "A" rejoins the semaphore queue at the head of the queue
      b) "A" rejoins the semaphore queue at the tail of the queue
   2) the initial key is rescinded. "A" suspends and when it
      resumes, it waits for 2 keys. Same sub-cases as (1). This
      is what I'd call the "resource management" view.
   3) "A" continues waiting on the semaphore until the "get(2)"
      is satisfied. It then suspends and upon a "resume"
      becomes active at the statement following the "get(2)". This
      is what I'd call the "linearization view".

The philosophical question impacts whether the "fifo" behavior
of semaphore scheduling is most important (i.e. linearization
of behavior) or whether resource management is. Personally
I think that option (1) is bad no matter what since that choice
breaks the (semi-)atomic assumptions and make a semaphore incompatible
with either the resource management or linearization view..

Pragmatically, we could also choose a 4th option -- make it
illegal (or a no-op) to suspend a process blocked on a semaphore.

Any opinions as to what people would prefer?

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.