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

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

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.

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

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. 

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