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

Jamie,

The extra "fair" flag was exactly what I was proposing. However, we
would have to
handle that as an enhancement for the next rev.

	Arturo

-----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
---------------------------------------------------------------------