Re: [Corelinux-develop] Questions (again)

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

On Fri, 25 Aug 2000, Hans - Dulimarta wrote:

> Date: Fri, 25 Aug 2000 12:19:36 -0400 (EDT)
> From: Hans - Dulimarta <dul...@eg...>
> Reply-To: cor...@li...
> To: cor...@li...
> Subject: Re: [Corelinux-develop] Questions (again)
> 
> On Fri, 25 Aug 2000, Frank V. Castellucci wrote:
> 
> > Date: Fri, 25 Aug 2000 06:58:07 -0400
> > From: Frank V. Castellucci <fr...@co...>
> > Reply-To: cor...@li...
> > To: cor...@li...
> > Subject: Re: [Corelinux-develop] Questions (again)
> > 
> > Hans - Dulimarta wrote:
> > > 
> > > I'm implementing EventSemaphore in the following setup:
> > > 
> > > Assuming we have three operations: down(), up(), and zero().
> > 
> > Are these the actual interface method names? While I don't feel the
> 
> No they are not. These are the Dijkstra primitives.
> 
> Operation | Dijkstra | IPC Semaphore
> ----------+----------+----------------------
> down(s)   |   P(s)   | semop (..., -1, ...)
> up()      |   V(s)   | semop (..., -1, ...)

Sorry, it was a mistake.   As you might guess up() should be 
semop (..., +1, ...)

> zero()    |   ----   | semop (...,  0, ...) 
> 
> > requirements document quite addresses is, the semantics of an Event are
> > things more like hold/trigger/waitFor
> > 
> > > When an EvSem is created, its value is initialized to 1 indicating the
> > > expected event has not occured.
> > 
> > I assume this is 'up', which I would consider 'hold'.
> 
> I use setValue(1) in the code.
> 
> > 
> > > Any callers who are waiting for the event to occur will do a "lock"
> > > by calling zero(). When the event actually takes place, the semaphore will
> > > be released via the down() operation.
> > 
> > Terminology shift, callers 'waitFor' events no? and the owner 'triggers'
> > them (to trigger an Event)?
> 
> But the interface of EventSemaphore does not have waitFor() function
> member. I could find release(), lockWait(), lockTimeOut(), and
> lockNoWait(). I assume the interface design is completed for
> EventSemaphore so, I was trying to implement the semantic of hold,
> trigger, and waitFor using those four member functions with the following
> mapping:
> 
> creator/owner   hold    --> init. sem to 1  : SemComm::setValue(1)
> event observer  waitFor --> lock<XYZ>()     : SemComm::setZero ()
> creator/owner   trigger --> release()       : SemComm::setLock ()
> 
> SemComm is SemaphoreCommon class.
> 
> The last two lines might look weird. Usually lock<XYZ> calls setLock() and
> release() calls setUnlock(), but the users of EventSemaphore class
> know the interface and semantic of the interface, they do not aware of of
> these interfaces are implemented.
> 
> > 
> > > The requirement document (SRS ?) for says that the Many-to-One semaphores
> > > will automatically lock upon creation and there is no option to create in
> > > unlock. When I look at the code, lock is similar to down() semaphore
> > > operation which implies that the creator will be block in the middle of
> > > the EventSemaphore ctor.
> > > 
> > > In the context of the above three operations, how can the creator perform
> > > a release operation to indicate that the expected event has occured?
> > 
> > There are two things to consider here:
> > 
> > 1. As the SemaphoreGroup instantiates the creation of the Semaphore (in
> > this case EventSemaphore), it can construct and then call 'hold'.
> >
> 
> Is it correct if I interpret 'hold' as initializing the semaphore to 1,
> hence automatically bringing the semaphore to a 'lock' state as mentioned
> in the SRS.
>  
> > 2. The owner of a semaphore is not in a blocked state, the Linux kernel
> > semaphore has a state change, but the owner is not blocked. Only those
> > callers 'waiting for' an event are blocked.
> > 
> 
> I am confused here. Does 'hold' also mean claiming ownership?  Who are
> 'owner' and 'creator/instantiator'? Are these two entities the different?
> If they are different, how can the creator pass ownership to the
> owner?
> 
> > Hope this helps.
> 
> Yes, it does a lot. But maybe more questions to come... :-)
> 
> > 
> > > --
> > > 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