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

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

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? 

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