Menu
▾
▴
corelinux-develop
|
From: Hans - D. <dul...@eg...> - 2000-08-31 20:45:27
|
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. -- 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 |
|
From: Frank V. C. <fr...@co...> - 2000-08-31 21:29:20
|
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 |
|
From: Hans - D. <dul...@eg...> - 2000-09-01 05:32:38
|
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
|
|
From: Frank V. C. <fr...@co...> - 2000-09-01 11:06:47
|
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
|
|
From: Hans - D. <dul...@eg...> - 2000-09-02 07:17:42
|
On Fri, 1 Sep 2000, Frank V. Castellucci wrote:
> Date: Fri, 01 Sep 2000 07:09:28 -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 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.
> >
> > 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
The existing interface does not have this option. I think balking and
recursion cannot be used for specifying this option. Perhaps, we should
have a function that is called "registerEvent"
> b) has some indication (getReleaseCount()?) that the event has been
> called n times since a reset
>
I'll try to implement both of these features in release >= 0.4.28.
> > --
> > 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
|
|
From: Frank V. C. <fr...@co...> - 2000-09-02 10:37:03
|
Hans - Dulimarta wrote:
>
> On Fri, 1 Sep 2000, Frank V. Castellucci wrote:
>
> > Date: Fri, 01 Sep 2000 07:09:28 -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 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.
> > >
> > > 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
>
> The existing interface does not have this option. I think balking and
> recursion cannot be used for specifying this option. Perhaps, we should
> have a function that is called "registerEvent"
>
> > b) has some indication (getReleaseCount()?) that the event has been
> > called n times since a reset
> >
>
> I'll try to implement both of these features in release >= 0.4.28.
Yeah, good call. I agree.
>
> > > --
> > > 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
|
