Re: [Corelinux-develop] Questions (again)

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

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

Ok.

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

Yes

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

The owner is the first one to actually "create" the semaphore. All
others should be looking for the existence of that semaphore.

So lets say I have 4 threads, 3 of which are interested in an event:

Thread 1 creates the EventSemaphoreGroup, and then asks to create the
Semaphore. The SemaphoreGroup does so, and the Thread 1 is the
owner/creator and the sem has a value of 1.

The other three (3) threads then, in effect, open that semaphore and use
the lock<XYZ> interface as you described.

When Thread 1 wants to indicate that the event has occured, it call
release.

The trick now is "When does Thread 1 KNOW when to put the semaphore back
into value 1?" This was something that I found to be an issue, not a
difficult one I imagine, but we may consider that, given they are all
sharing the same semaphore instance, that events keep track of how was
released and sets another Guarded flag when the number of listeners have
all been serviced.

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