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

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

Hans - Dulimarta wrote:
> 
> On Thu, 31 Aug 2000, Frank V. Castellucci wrote:
> 
> > Date: Thu, 31 Aug 2000 17:32:02 -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 have come to the conclusion mentioned in the subject line.
> > >
> > > The way I understand 'recursion' in the context of a semaphore is as
> > > follow. A thread has a lock on a semaphore and wants to lock it again.
> > > Is this right?
> > >
> > > In the case of Mutex and Gateway, obtaining a lock means gaining access to
> > > a resource and hence the thread is actively performing some work. However,
> > > in the case of Event, obtaining a lock means that the requesting thread is
> > > willing to stop working and wait (i.e. block itself) until an event
> > > occurs.
> > >
> > > So, if the requesting thread is blocked for an event (in the queue of the
> > > corresponding EventSemaphore), it would never be possible for this thread
> > > to recurse and try to obtain any other lock.
> > >
> > > Please verify this statement. Your comments will affect how the
> > > EventSemaphore is implemented.
> >
> > As I generally agreed earlier, you are correct in the assertion that
> > when a thread indicates it wants to wait (block) on a thread, it can't
> > (by definition) recurse because for all intents and purposes, it isn't
> > running.
> >
> 
> 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.
> 
> > Now, if you are going to make this a invarient state of the object
> > instance that the thread has, you will need to address the following:
> >
> > 1. When the event is signaled, and listening thread gets control, what
> > happens if it calls immediatley to register a "wait" again? This may be
> > negated by your definition of "queue".
> >
> 
> 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 
b) has some indication (getReleaseCount()?) that the event has been
called n times since a reset
 
> --
> 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