Re: [Corelinux-develop] Recursion of EventSemaphore is impossible

[Hans - D. <dul...@eg...>]

On Fri, 1 Sep 2000, Frank V. Castellucci wrote:

> Date: Fri, 01 Sep 2000 07:09:28 -0400
> From: Frank V. Castellucci <fr...@co...>
> Reply-To: cor...@li...
> To: cor...@li...
> Subject: Re: [Corelinux-develop] Recursion of EventSemaphore is impossible
> 
> Hans - Dulimarta wrote:
> > 
> > 
> > I forgot to tell you that the implementation of the EventSemaphore
> > is now different from what I proposed earlier.
> > 
> > It was like this:
> > 
> > Owner/Creator holds    --> setValue(1)   --> initialize sem to 1
> > Listener waits         --> lock<XYZ>()   --> Z(s)
> > Owner/Creator triggers --> release()     --> P(s)
> > 
> > It is now like this:
> > 
> > Owner/Creator holds    --> setValue(-1)  --> initialize sem to -1
> > Listener waits         --> lock<XYZ>()   --> Z(s)
> > Owner/Creator triggers --> release()     --> V(s)
> > 
> > with
> > Z(s) = kernel call to semop {..., 0, ...} via waitZero() [added function]
> > P(s) = kernel call to semop {..., 1, ...} via setLock()
> > V(s) = kernel call to semop {...,-1, ...} via setUnLock()
> > 
> > with the new implementation the release() function looks natural.
> > 
> > I view the lockWith{Wait,NoWait,Timeout}() as the wrapper of the
> > Dijkstra's P() [or Z()] operation and release() as the wrapper of the V()
> > operation. As defined, these P,V, [and Z] operations are atomic ones
> > meaning that they are _interruptible_. With this definition, when the
> > event is signalled, the triggering thread will run its release until
> > completion (finishing "reset" and "cleanup") and then the listening
> > thread(s) will get control. So when the listening thread immediately calls
> > to register another lockWith<XYZ> again, this call will be made to the
> > semaphore which is already reset and cleaned up and therefore it is not
> > a recursive call.
> > 
> > > 2. Some processes will require that they indicate an interest in the
> > > event, but will come back later to see if it were signalled yet.
> > >
> > 
> > Are talking about the lockWithNoWait call?
> 
> No, it is more like a "make a note that I am interested to know if the
> semaphore has been released, and if so, how many times since I last
> asked", this was a feature of OS/2 and subsequently WinNT semaphores. So
> the listener :
> 
> a) is not blocked when Z(s) is called even though they remain a
> participant 

The existing interface does not have this option. I think balking and
recursion cannot be used for specifying this option. Perhaps, we should
have a function that is called "registerEvent"

> b) has some indication (getReleaseCount()?) that the event has been
> called n times since a reset
>

I'll try to implement both of these features in release >= 0.4.28.

> > --
> > Hans Dulimarta, Ph.D.                  dul...@co...
> > P: 517-432-7589             http://www.egr.msu.edu/~dulimart
> > F: 760-281-7691             http://corelinux.sourceforge.net
> > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > 
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> 
> 

-- 
Hans Dulimarta, Ph.D.                  dul...@co...
P: 517-432-7589             http://www.egr.msu.edu/~dulimart   
F: 760-281-7691             http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824