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

[Frank V. C. <fr...@co...>]

Hans - Dulimarta wrote:
> 
> 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.

Yeah, good call. I agree.

> 
> > > --
> > > 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
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package