Re: [sv-bc] Semaphore question

Hi, All -

A good question, but I disagree with Jamie's interpretation.

From the P1800 LRM:
---------------
14.2.3 get()

...

If the specified number of keys are available, the method returns and
execution continues. If the specified number of key are not available, the
process blocks until the keys become available.

The semaphore waiting queue is First-In First-Out (FIFO). This does not
guarantee the order in which processes arrive at the queue, only that
their arrival order shall be preserved by the semaphore.
---------------

I interpret this to be a c.get(2) method tries to request two keys when
only one is available and a subsequent d.get(1) method is pushed onto the
semaphore-fifo and must wait for first-in to be first-out, otherwise, it
is not true fifo order because second-in can be first-out if first-in is
blocked and there are sufficient keys for second-in to satisfy the
request.

I would not mind clarification wording such as:
-------------
The semaphore waiting queue is First-In First-Out (FIFO). This does not
guarantee the order in which processes arrive at the queue, only that
their arrival order shall be preserved by the semaphore and a blocked
semaphore will block subsequent semaphore requests until the first
semaphore's request is satisfied, even if there are enough keys to
immediately satify the request from a later semaphore request.
--------------

Regards - Cliff

> The LRM description for semaphore::get() includes the following two
> statements:
>
>     (1) If the specified number of keys are available, the method
> returns and execution continues.
>     (2) The semaphore waiting queue is First-In First-Out (FIFO).
>
> If I'm interpreting (1) and (2) correctly, then the behavior would be
> somewhat inconsistent when handling requests for different numbers of
> keys.  My interpretation is that in this example:
>
>     semaphore c = new(1);
>     initial c.get(2);    // process 1 blocks
>     initial #1 c.get(1); // process 2 executes without blocking
>     initial #2 c.put(2); // causes process 2 to execute
>
> the request for 1 key will be satisfied before the request for 2 keys
> because the get(1) never gets put on the waiting queue.  On the other
> hand, in this example:
>
>     semaphore c = new(0);
>     initial c.get(2);     // process 1 blocks
>     initial #1 c.get(1);  // process 2 blocks
>     initial #2 c.put(1);  // neither process 1 or process 2 resumes
>
> process 2 never unblocks because process 1 is first in the waiting queue
> and the queue must maintain FIFO ordering.  This seems somewhat
> inconsistent - am I misinterpreting the LRM or does the LRM need to be
> clarified?
>
> Thanks,
> -Jamie
>