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

Arturo Salz wrote:
> Any reason why I’m getting multiple copies of this message? Is it just me?

Sorry about that -- I was using a web interface last evening and
it sent stuff out multiple times. I have no idea why.

> I too recall that discussion. As I recall, the original intent was for
> the semaphore key allocation to be atomic and the queue waiting to be
> ordered (FIFO). That means that a process requesting 1 key should be
> able to jump ahead of another process that was already waiting for 2
> keys (when only one was available). I also recall that we could
> accommodate the two behaviors by providing an additional flag to the
> semaphore to ensure fairness – and force all request (as well as the
> queue) to be strictly FIFO.

Well, if we want to have different protocols supported by a semaphore
that should certainly be in the standard.

> As to the interaction between semaphore and suspend, I’m somewhat
> sympathetic to John’s viewpoint that some things are probably best left
> out of the standard.

I disagree. End user expectations of fairness and planning for
starvation are critical. If a user can't rely on which of the
alternatives I suggested will be in play, they can't design for
a robust solution. That is particularly true if try_get is
also impacted in terms of fairness decisions. If the user could
otherwise play with scheduling themselves, that would be different,
but these are in fact the fundamental building blocks that people
need in order to be able to define their own policies and build
other approaches. Having them have ill-defined interactions will
lead to issues.

> I think that to be consistent with the existing
> verbiage of the LRM, a process waiting for a semaphore will have to be
> removed from the semaphore queue and then re-execute the get once it
> has been resumed. I’m not particularly happy about such an outcome, but
> I believe it would be consistent.

I somewhat agree (the comments in the LRM about re-sensitizing on
other conditions would be consistent with that) but that is also
why I brought up the scenarios. Such an interpretation is definitely
opposed to the fifo behavior that is otherwise described and that
others are assuming (see other responses). In particular, whether
the suspend causes a partial request to be relinquished and
re-started from the beginning or end of the queue would also need
to be defined.

I would be fine with added a constructor argument to the standard
semaphore that defines "strict fifo" or "eager" policies and then
add some definition about suspend.

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.