Re: [sv-ec] [sv-bc] Semaphore question

I'm with Steven.

This issue is why counting semaphores traditionally only
allow a single request even though you can do a multiple
release.  Allowing a multi-request can cause process
starvation if you have high-frequency single requests
that never allow the count to reach the number of the
multi-request.  Allowing only single requests means
that a request for N iterates and could block multiple
times but will eventually succeed if progress is being
made in the system.

I don't like the semantics that Arturo is suggesting.  Do
we really want to increase the chances of starvation
in sytems?

Gord.


Steven Sharp wrote:

> Arturo,
> 
> Then what is the point of specifying the FIFO order for the semaphore
> wait queue, if you are going to leave this hole?  With this hole, it
> doesn't provide fairness, potentially leaving processes starved forever.
> It doesn't provide determinism either, since arrival time is not
> necessarily deterministic.
> 
> Regardless of the intent, I don't agree that the text is unambiguous.
> I think that my suggested interpretation is plausible from the existing
> text, and is supported by the apparent desire for fairness indicated by
> the FIFO ordering.  If the text had said that "the process is added to
> the semaphore waiting queue and blocks until the keys become available"
> then it would have been clear.  That would have indicated that the
> semaphore waiting queue consists only of processes that blocked.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com