Menu
▾
▴
corelinux-develop — Developer centric mail list for CoreLinux++
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(144) |
Aug
(209) |
Sep
(117) |
Oct
(44) |
Nov
(41) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(14) |
Feb
(64) |
Mar
(25) |
Apr
(35) |
May
(29) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(12) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(7) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
(9) |
Jun
(11) |
Jul
(9) |
Aug
(5) |
Sep
(7) |
Oct
|
Nov
|
Dec
(9) |
| 2007 |
Jan
(3) |
Feb
(5) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(16) |
Sep
(7) |
Oct
(8) |
Nov
(8) |
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
(7) |
Mar
(27) |
Apr
(26) |
May
(28) |
Jun
(17) |
Jul
(38) |
Aug
(13) |
Sep
(17) |
Oct
(12) |
Nov
(37) |
Dec
(51) |
| 2009 |
Jan
(41) |
Feb
(19) |
Mar
(30) |
Apr
(43) |
May
(138) |
Jun
(111) |
Jul
(76) |
Aug
(27) |
Sep
(28) |
Oct
(33) |
Nov
(11) |
Dec
(18) |
| 2010 |
Jan
(3) |
Feb
(5) |
Mar
(40) |
Apr
(51) |
May
(74) |
Jun
(76) |
Jul
(46) |
Aug
(41) |
Sep
(26) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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-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 02:04:14
|
Christophe Prud'homme wrote: > > > 2. Updated Developers Docs (required) > I can work on that since I made the changes > and it is a good exercise :) > > > 3. Updated README , ChangeLog (required) > > 4. Updated web pages (required) > > -in the dl page just change the version number at the top of the php file > - add a clfw section in the dl page > I can do that > > > > > For clfw, there really is no documentation other than the reference > > pages in clfw-doc, which may be ok for the time being as long as I > > reference the requirement and design models on the web. > > > > Thoughts? > I think so too > there is still this old adage: << use the code, luc! use the code! >>:) > since it is a tech preview and that should be fine > > I go back home now > see ya tomorrow > > C. > It seems that the doc-*.rpm is broken again. It doesn't include the PDF or the PS (although the directories are there), and it now includes the examples html. Did you change the cfg for doxygen or the spec file somehow? If you do not respond I will take a look, if I can't figure I will post a defect with your name on it :) -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Christophe Prud'h. <pru...@mi...> - 2000-09-01 01:44:25
|
> 2. Updated Developers Docs (required) I can work on that since I made the changes and it is a good exercise :) > 3. Updated README , ChangeLog (required) > 4. Updated web pages (required) -in the dl page just change the version number at the top of the php file - add a clfw section in the dl page I can do that > > For clfw, there really is no documentation other than the reference > pages in clfw-doc, which may be ok for the time being as long as I > reference the requirement and design models on the web. > > Thoughts? I think so too there is still this old adage: << use the code, luc! use the code! >>:) since it is a tech preview and that should be fine I go back home now see ya tomorrow C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | C'est de la buche? Cambridge MA 02139 | Non c'est kloug! Tel (Office) : (00 1) (617) 253 0229 | C'est colmatté avec du schpountz... Fax (Office) : (00 1) (617) 258 8559 | -- Le Pere Noel est une ordure http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-09-01 01:42:19
|
Christophe Prud'homme wrote: > > On Thu, 31 Aug 2000, you wrote: > > I changed and check-in for 0.4.27 release number change. > I just update the shared lib version to 1:0:0 > ok, couple of points and questions clfw will remain shared lib 0:0:0 for some time, first release will be 0.1.0 (I will make the changes) now, ideally, clfw should require some level to be expected from corelinux to install. We now check for cl++ but I would like to get it to check for 1:0:0 as well. Is there a way to do this from rpm? -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-09-01 01:38:25
|
Christophe Prud'homme wrote: > > tomorrow I can give some time for the release :)! > shall we do that or wait some time to test the 0.4.27? > > C. > -- Well, I am going through some testing now (rpm build, install, clfw rpm build, install, etc.). There are a few things that would need to be done, which I mark as optional or required for 0.4.27 1. Hans EventSemaphore (optional) 2. Updated Developers Docs (required) 3. Updated README , ChangeLog (required) 4. Updated web pages (required) For clfw, there really is no documentation other than the reference pages in clfw-doc, which may be ok for the time being as long as I reference the requirement and design models on the web. Thoughts? -- Frank V. Castellucci |
|
From: Christophe Prud'h. <pru...@mi...> - 2000-09-01 01:29:06
|
tomorrow I can give some time for the release :)! shall we do that or wait some time to test the 0.4.27? C. -- Christophe Prud'homme | A classic is something that MIT, 77, Mass Ave, Rm 3-243 | everyone wants to have read and Cambridge MA 02139 | nobody wants to read. Tel (Office) : (00 1) (617) 253 0229 | -- Mark Twain, Fax (Office) : (00 1) (617) 258 8559 | "The Disappearance of Literature" http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-01 01:27:45
|
On Thu, 31 Aug 2000, you wrote: > I changed and check-in for 0.4.27 release number change. I just update the shared lib version to 1:0:0 -- Christophe Prud'homme | Pierre: Je suis désolé Thérèse, je ne MIT, 77, Mass Ave, Rm 3-243 | sais pas ce qui m'a pris... Cambridge MA 02139 | c'est une catastrophe. Tel (Office) : (00 1) (617) 253 0229 | Thérèse: Ce n'est rien Pierre, Fax (Office) : (00 1) (617) 258 8559 | je n'ai rien senti.... http://augustine.mit.edu/~prudhomm | -- Le Pere Noel est une ordure Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-09-01 01:22:07
|
I changed and check-in for 0.4.27 release number change. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-09-01 00:57:31
|
Yes, this is where I had the problem. My work around was to do a make install-includeHEADER as the target for include/clfw so it only put the two files, and then add another install line for LibLoad. If you look at the %install section of the spec you will see what I mean. See, now I am dangerous :) Christophe Prud'homme wrote: > > Hi > Now clfw has its own debian packages > but > the .h go in /usr/include/cflfw > shouldn't it go to /usr/include/cflfw/LibLoad or something like that? > > I'll have a look at the spec file to get the same directories framework > > C. > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme > Cambridge MA 02139 | d'honneur et de valeur, > Tel (Office) : (00 1) (617) 253 0229 | sage et loyal. > Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand > http://augustine.mit.edu/~prudhomm | > Following the hacker spirit > _______________________________________________ > 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: Christophe Prud'h. <pru...@MI...> - 2000-09-01 00:52:55
|
Hi Now clfw has its own debian packages but the .h go in /usr/include/cflfw shouldn't it go to /usr/include/cflfw/LibLoad or something like that? I'll have a look at the spec file to get the same directories framework C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme Cambridge MA 02139 | d'honneur et de valeur, Tel (Office) : (00 1) (617) 253 0229 | sage et loyal. Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-31 23:15:58
|
I updated clfw because of incompatibilites with the CORELINUX macros arg order now it is compiling fine with the newest corelinux cvs now I focus on the packages issues I will generate the debian packages for corelinux and clfw more details soon C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | The Second Law of Thermodynamics: Cambridge MA 02139 | If you think things are in a mess Tel (Office) : (00 1) (617) 253 0229 | now, just wait! Fax (Office) : (00 1) (617) 258 8559 | -- Jim Warner http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-31 22:57:52
|
Ok I updated corelinux cvs huge update! I still have to create the corelinux-dbg package for redhat Frank I will look into the packaging problems you mentionned C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme Cambridge MA 02139 | d'honneur et de valeur, Tel (Office) : (00 1) (617) 253 0229 | sage et loyal. Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
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-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 02:45:47
|
If you are updating make sure to 'cvs update -Pd' as I moved files and directories around a bit. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-08-31 02:45:08
|
Finally figured out the rpm issues and am able to create the multi-level header directory required. There is probably a better way, but it works for now. I'm going to try and visually check the debian files for updates (as I copied them from corelinux) so that at which point C. is done doing whatever, that build can be tested. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-08-30 15:22:21
|
Hans - Dulimarta wrote: > > On Wed, 30 Aug 2000, Frank V. Castellucci wrote: > > > Date: Wed, 30 Aug 2000 06:57:38 -0400 > > From: Frank V. Castellucci <fr...@co...> > > Reply-To: cor...@li... > > To: cor...@li... > > Subject: Re: [Corelinux-develop] Recursion in EventSemaphore > > > > Hans - Dulimarta wrote: > > > > > > The signature of the EventSemaphore constructor does not have any formal > > > parameter which can be used to specify the maximum limit of listeners. > > > I could not find this either in the .mdf files. > > > > > > Again, I am assuming that the design of EventSemaphore class interface > > > is final and I am not supposed to change it. > > > > No, it was an oversight on my part as I knew it was not low fruit on the > > tree. It SHOULD have it as per the requirement. > > > > OK, I have changed the the signature of EventSemaphore ctor to include > a limit of maximum listeners with the following semantic: > > < 0 : infinite number of listeners > 0 : no listeners are allowed > > 0 : finite number of listeners > > And probably we have to add the setLimit and getLimit member functions > as well. The setLimit() function can be called only by the owner. setLimit being protected so derived types can use it as well, other than that...cool! > > Any comments? > > > > > > > > > So, from what I could understand by reading the code and the "manual", > > > > > for this "infinite" listener version of EvSem the recursion mode is > > > > > irrelevant. Am I making a correct assumption? > > > > > > > > It feels like it would be irrelevant to register a single thread more > > > > than once. I assume that you are tracking which threads are listening on > > > > a EventSemaphore and can detect this? If so, the question remains, is it > > > > an error or intentional usage by the user? > > > > > > How is it possible for a single thread to register more than once. > > > Once a thread register (wait for event) it will be blocked until the > > > event takes place, or if it enables balking mode it will not be registered > > > and hence it won't be blocked. > > > > > > No, I don't keep any track of who are listening to the event. I prefer to > > > make the data member of EventSemaphore as minimal as possible. > > > > Ok > > > > > > > > > > > -- > > > > > 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 > > > > > > -- > 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-08-30 15:02:06
|
On Wed, 30 Aug 2000, Frank V. Castellucci wrote: > Date: Wed, 30 Aug 2000 07:00:46 -0400 > From: Frank V. Castellucci <fr...@co...> > Reply-To: cor...@li... > To: cor...@li... > Subject: Re: [Corelinux-develop] EventSemaphoreGroup > > Hans Dulimarta wrote: > > > > I think I have a preliminary version of EventSemaphore. > > > > In my local directory, the following files have been > > modified: > > AbstractSemaphore.* > > SemaphoreCommon.* > > > > and the following files will be added to the repository: > > EventSemaphore.[cpp,hpp] > > > > In one of the previous e-mails it was written that > > EventSemaphoreGroup > > has to be implemented. But, I could not find the design of > > EventSemaphoreGroup. > > Is it "hidden" somewhere in the CVS tree? > > No, like EventSemaphore.[cpp,hpp], it needs to be created. > OK, I'll copy the class interface from the other *SemaphoreGroup class and modify it for EventSemaphoreGroup. -- 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: Hans - D. <dul...@eg...> - 2000-08-30 14:56:23
|
On Wed, 30 Aug 2000, Frank V. Castellucci wrote:
> Date: Wed, 30 Aug 2000 06:57:38 -0400
> From: Frank V. Castellucci <fr...@co...>
> Reply-To: cor...@li...
> To: cor...@li...
> Subject: Re: [Corelinux-develop] Recursion in EventSemaphore
>
> Hans - Dulimarta wrote:
> >
> > The signature of the EventSemaphore constructor does not have any formal
> > parameter which can be used to specify the maximum limit of listeners.
> > I could not find this either in the .mdf files.
> >
> > Again, I am assuming that the design of EventSemaphore class interface
> > is final and I am not supposed to change it.
>
> No, it was an oversight on my part as I knew it was not low fruit on the
> tree. It SHOULD have it as per the requirement.
>
OK, I have changed the the signature of EventSemaphore ctor to include
a limit of maximum listeners with the following semantic:
< 0 : infinite number of listeners
0 : no listeners are allowed
> 0 : finite number of listeners
And probably we have to add the setLimit and getLimit member functions
as well. The setLimit() function can be called only by the owner.
Any comments?
> >
> > > > So, from what I could understand by reading the code and the "manual",
> > > > for this "infinite" listener version of EvSem the recursion mode is
> > > > irrelevant. Am I making a correct assumption?
> > >
> > > It feels like it would be irrelevant to register a single thread more
> > > than once. I assume that you are tracking which threads are listening on
> > > a EventSemaphore and can detect this? If so, the question remains, is it
> > > an error or intentional usage by the user?
> >
> > How is it possible for a single thread to register more than once.
> > Once a thread register (wait for event) it will be blocked until the
> > event takes place, or if it enables balking mode it will not be registered
> > and hence it won't be blocked.
> >
> > No, I don't keep any track of who are listening to the event. I prefer to
> > make the data member of EventSemaphore as minimal as possible.
>
> Ok
>
> > >
> > > > --
> > > > 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
>
>
--
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-30 10:58:06
|
Hans Dulimarta wrote: > > I think I have a preliminary version of EventSemaphore. > > In my local directory, the following files have been > modified: > AbstractSemaphore.* > SemaphoreCommon.* > > and the following files will be added to the repository: > EventSemaphore.[cpp,hpp] > > In one of the previous e-mails it was written that > EventSemaphoreGroup > has to be implemented. But, I could not find the design of > EventSemaphoreGroup. > Is it "hidden" somewhere in the CVS tree? No, like EventSemaphore.[cpp,hpp], it needs to be created. > > -- > 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: Frank V. C. <fr...@co...> - 2000-08-30 10:55:00
|
Hans - Dulimarta wrote: > > On Tue, 29 Aug 2000, Frank V. Castellucci wrote: > > > Date: Tue, 29 Aug 2000 06:44:41 -0400 > > From: Frank V. Castellucci <fr...@co...> > > Reply-To: cor...@li... > > To: cor...@li... > > Subject: Re: [Corelinux-develop] Recursion in EventSemaphore > > > > Hans - Dulimarta wrote: > > > > > > For the next release (0.4.27), I will implement EventSemaphore with > > > "infinite" number of listeners. Any process/thread that wants to wait > > > for an event (lock itself to the event) will be allowed to do so. > > > > Thats fine, but the requirement does call for limiting the number of > > listeners (see Balking), which would turn away threads when the limit is > > reached. > > > > The signature of the EventSemaphore constructor does not have any formal > parameter which can be used to specify the maximum limit of listeners. > I could not find this either in the .mdf files. > > Again, I am assuming that the design of EventSemaphore class interface > is final and I am not supposed to change it. No, it was an oversight on my part as I knew it was not low fruit on the tree. It SHOULD have it as per the requirement. > > > > So, from what I could understand by reading the code and the "manual", > > > for this "infinite" listener version of EvSem the recursion mode is > > > irrelevant. Am I making a correct assumption? > > > > It feels like it would be irrelevant to register a single thread more > > than once. I assume that you are tracking which threads are listening on > > a EventSemaphore and can detect this? If so, the question remains, is it > > an error or intentional usage by the user? > > How is it possible for a single thread to register more than once. > Once a thread register (wait for event) it will be blocked until the > event takes place, or if it enables balking mode it will not be registered > and hence it won't be blocked. > > No, I don't keep any track of who are listening to the event. I prefer to > make the data member of EventSemaphore as minimal as possible. Ok > > > > > -- > > > 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 |
|
From: Hans D. <dul...@eg...> - 2000-08-30 04:10:14
|
I think I have a preliminary version of EventSemaphore. In my local directory, the following files have been modified: AbstractSemaphore.* SemaphoreCommon.* and the following files will be added to the repository: EventSemaphore.[cpp,hpp] In one of the previous e-mails it was written that EventSemaphoreGroup has to be implemented. But, I could not find the design of EventSemaphoreGroup. Is it "hidden" somewhere in the CVS tree? -- 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: Christophe Prud'h. <pru...@MI...> - 2000-08-30 01:13:02
|
Ok I am not really online these days I will read the email tonight see ya C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Do nothing unless you must, Cambridge MA 02139 | and when you must act Tel (Office) : (00 1) (617) 253 0229 | -- hesitate. Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Hans - D. <dul...@eg...> - 2000-08-29 23:48:52
|
On Tue, 29 Aug 2000, Frank V. Castellucci wrote: > Date: Tue, 29 Aug 2000 06:44:41 -0400 > From: Frank V. Castellucci <fr...@co...> > Reply-To: cor...@li... > To: cor...@li... > Subject: Re: [Corelinux-develop] Recursion in EventSemaphore > > Hans - Dulimarta wrote: > > > > For the next release (0.4.27), I will implement EventSemaphore with > > "infinite" number of listeners. Any process/thread that wants to wait > > for an event (lock itself to the event) will be allowed to do so. > > Thats fine, but the requirement does call for limiting the number of > listeners (see Balking), which would turn away threads when the limit is > reached. > The signature of the EventSemaphore constructor does not have any formal parameter which can be used to specify the maximum limit of listeners. I could not find this either in the .mdf files. Again, I am assuming that the design of EventSemaphore class interface is final and I am not supposed to change it. > > So, from what I could understand by reading the code and the "manual", > > for this "infinite" listener version of EvSem the recursion mode is > > irrelevant. Am I making a correct assumption? > > It feels like it would be irrelevant to register a single thread more > than once. I assume that you are tracking which threads are listening on > a EventSemaphore and can detect this? If so, the question remains, is it > an error or intentional usage by the user? How is it possible for a single thread to register more than once. Once a thread register (wait for event) it will be blocked until the event takes place, or if it enables balking mode it will not be registered and hence it won't be blocked. No, I don't keep any track of who are listening to the event. I prefer to make the data member of EventSemaphore as minimal as possible. > > > -- > > 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 |
1115 messages has been excluded from this view by a project administrator.
