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

Note that the semaphore is just a built-in class that could be extended
if the user wants to change the behavior when there are more then one
keys

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> LaFlamme, Jamie
> Sent: Monday, September 19, 2005 10:26 AM
> To: sv-ec@eda.org
> Subject: RE: [sv-ec] [sv-bc] Semaphore question
> 
> The problem is that there is no easy way to take advantage of the
extra
> flexibility right now.  If users want strict FIFO ordering they'd have
> to go to extreme lengths to make it work.  If we want this
flexibility,
> it seems like we should add a constructor argument - at least that way
> the user will know what behavior to expect.
> 
> -Jamie
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Neil
> Korpusik
> Sent: Thursday, September 15, 2005 4:07 PM
> To: Vreugdenhil, Gordon
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] [sv-bc] Semaphore question
> 
> I agree with Steven that the LRM could be made more explicit in this
> regard.
> 
> What Arturo is suggesting is that there are different user
requirements
> that can be met when applying the algorithm he has described. In some
> situations it is desirable to enforce fairness and in other situations
> some threads should have priority. If each thread requests the same
> number of keys then fairness is enforced. A priority scheme can be
> created by having different threads request different numbers of keys.
> 
> Using the approach described by Arturo allows for more flexibility.
With
> this approach the user is allowed to decide how to use the semaphore
to
> achieve the objective he has in mind. I can understand how Cliff came
to
> the conclusion that he did given the existing text in the LRM but I
> believe that what Arturo has described is preferable and what was
> originally intended.
> 
> 
> Gordon Vreugdenhil wrote On 09/15/05 15:31,:
> > 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
> >>
> >>
> >
> >
> 
> --
> ---------------------------------------------------------------------
> Neil Korpusik                                     Tel: 408-720-4852
> Staff Engineer                                    Fax: 408-720-4850
> Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems
> email: neil.korpusik@sun.com
> ---------------------------------------------------------------------
> 
>