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-08-29 10:42:03
|
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. > 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? > -- > 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-29 06:31:06
|
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. 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? -- 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-28 23:14:30
|
The clfw stuff is ALMOST working, but I am having trouble with defining both the include dirs in the %pacakage dev area. I don't know if I should make LibLoad header directory a subdirectory of clfw: /clfw /clfw /LibLoad as it currently is /clfw /clfw /LibLoad I got it to build the RPM's correctly until I noticed that the /LibLoad header files were missing. Christophe, if you have two minutes to take a look. It is all in CVS Thnx -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-08-28 11:08:38
|
Hans Dulimarta wrote: > > "Frank V. Castellucci" wrote: > > > > Christophe: > > All changes for 2.96.x that don't break >= 2.95.2 > > > > Hans: > > EventSemaphoreGroup, EventSemaphore > > > > I can write example code for EventSemaphore if needed, Hans? > > > > Yes please, that will be a lot of help for me to understand > how the > code should be implemented. Please let me know when you have > the > examples ready. > > Are you going to put in in repository or send me via e-mail? No Hans, I meant when you are done I can write the example if you are pressed for time. > > I made a commitment to finish the implementation this > weekend. > Apparently, I could not spend much time on it. Friday > evening I was > not feeling well, Saturday I had to go to Detroit to visit a > friend > who is leaving for Indonesia. > Sunday afternoon, I was invited to a farewell party by a > friend whose > son will spend 1 year in Kosovo. > > I just returned to my computer Sunday evening.... > > When is the release date of 0.4.27, I'll try to catch it up. <GRIN>, well, Christophe has a number of changes that when he checks in, you should update your distribution to build with due to the changes he made, and when you check in I will then write the sample if you already have not. We will then release 0.4.27. > > > > > -- > > Frank V. Castellucci > > _______________________________________________ > > 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: Frank V. C. <fr...@co...> - 2000-08-28 10:29:54
|
Hans Dulimarta wrote: > > "Frank V. Castellucci" wrote: > > > > Christophe: > > All changes for 2.96.x that don't break >= 2.95.2 > > > > Hans: > > EventSemaphoreGroup, EventSemaphore > > > > I can write example code for EventSemaphore if needed, Hans? > > > > Yes please, that will be a lot of help for me to understand > how the > code should be implemented. Please let me know when you have > the > examples ready. > > Are you going to put in in repository or send me via e-mail? Hans, no, I meant that when you have something ready I can write an example around it. Sorry for the confusion. > > I made a commitment to finish the implementation this > weekend. > Apparently, I could not spend much time on it. Friday > evening I was > not feeling well, Saturday I had to go to Detroit to visit a > friend > who is leaving for Indonesia. > Sunday afternoon, I was invited to a farewell party by a > friend whose > son will spend 1 year in Kosovo. > > I just returned to my computer Sunday evening.... Don't worry about it. > > When is the release date of 0.4.27, I'll try to catch it up. It is when you are ready. I still will write an example around it once it is available, so that will take a day as well. > > > > > -- > > Frank V. Castellucci > > _______________________________________________ > > 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-28 02:26:41
|
"Frank V. Castellucci" wrote: > > Christophe: > All changes for 2.96.x that don't break >= 2.95.2 > > Hans: > EventSemaphoreGroup, EventSemaphore > > I can write example code for EventSemaphore if needed, Hans? > Yes please, that will be a lot of help for me to understand how the code should be implemented. Please let me know when you have the examples ready. Are you going to put in in repository or send me via e-mail? I made a commitment to finish the implementation this weekend. Apparently, I could not spend much time on it. Friday evening I was not feeling well, Saturday I had to go to Detroit to visit a friend who is leaving for Indonesia. Sunday afternoon, I was invited to a farewell party by a friend whose son will spend 1 year in Kosovo. I just returned to my computer Sunday evening.... When is the release date of 0.4.27, I'll try to catch it up. > > -- > Frank V. Castellucci > _______________________________________________ > 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-27 12:32:56
|
for clfw * library will be libclfw++.so, etc. (commited configure.in) * check-in ClfwCommon.hpp to /clfw/clfw * check-in LibraryLoad.hpp to /clfw/LibLoad What do you guys think is the better route to go: 1. for clfw, the major output would be one (1) library : libclfw++. I could set the makefiles up to include objects from all the abstracts (e.g. LibLoad, Persist). The advantage being that the developer need not worry about potentially large library includes and synchronization of more than one release. --or-- 2. Have multiple library output (which could get very busy), for example: libclfw++ (base stuff) libclfwll++ (Library Load) libclfwp++ (Persist) etc. this has the advantage of reducing the memory footprint if only extending one, or a few, abstractions at the expense of maintenance and version requirement correctness for co-dependent framework abstractions. My view: Although I started all the segregation talk, I would now postulate: 1. Most development extensions would use more than one abstract framework anyway 2. As a developer, I find it annoying to have to synchronize many different releases Thoughts? -- 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-08-26 21:07:33
|
> Ok, when you commit your changes let me know. Also, because of the > interface changes which break old code, would you be setting the > configure.in (LIBCORELINUX_SO_VERSION) to 1.1.0 ? Hum the interface is not broken codes should continue to run correctly however they won't compile because of the macros ! Oh no I am wrong I changed some interfaces with exceptions so we have to change the libtool version, you're right > And the clfw is NOT part of the 0.4.27 release. It will start to take a > life of it's own, but the first would be a 0.1.0 release. yes sure I certainly will update the cvs today 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-26 05:50:40
|
On Sat, 26 Aug 2000, you wrote: > Christophe: > All changes for 2.96.x that don't break >= 2.95.2 see previous email all examples are up and running everything is compiling fine -- 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-26 05:31:39
|
I just sent an email for a release proposal a few seconds ago and I received your mail about it that's amazing :) XFiles are very close :) see ya 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-26 05:26:40
|
we discussed shortly about the forthcoming release the release early or release often might not always be good it can be either a good or a bad marketing weapon testing code before release is something that you don't want to do generally and good testing frameworks may not be easy at all to setup depending on the project. However here what we can do for the next release: 1- on corelinux (tarball + packages): * hans work on semaphore (it is always good to have new features) * compilation fixes, c++ correctness * macro changes, will break existing codes * new -dbg package for debugging purpose 2- on clfw (tarball) * preview technology for the LibraryLoader comments? other stuff to add? my best regards C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | In theory, theory and practice Cambridge MA 02139 | are the same. In practice they Tel (Office) : (00 1) (617) 253 0229 | are different. Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-08-26 05:21:36
|
Christophe: All changes for 2.96.x that don't break >= 2.95.2 Hans: EventSemaphoreGroup, EventSemaphore I can write example code for EventSemaphore if needed, Hans? -- Frank V. Castellucci |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-26 05:14:40
|
I couldn't sleep so I change some CORELINUX macros now CORELINUX_LIST|VECTOR|STACK|QUEUE|MAP|MULTIMAP|SET|MULTISET reflects the arguments order of their stl counterpart thanks to perl my job was interesting :) one more defect to create good night C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | I respect faith, but doubt is Cambridge MA 02139 | what gives you an education. Tel (Office) : (00 1) (617) 253 0229 | -- Wilson Mizner Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Christophe Prud'h. <pru...@MI...> - 2000-08-26 03:02:35
|
On Fri, 25 Aug 2000, you wrote: > Ok, you mean #9 > > so thats Hans/Christophe for #9 > > So what do I need to tell the artist as far as format (png, eps,?), and > opaque background? formats: xcf (native gimp format), png, eps png supports transparent background so ask for transparent background if he cannot do that then ask for a gif file otherwise if we have the xcf then we can do anything after thoughts: 1- change the color of the O, just just draw two O, one embedding the other 2- two sizes for the logos, one size like on the web page and one twice smaller ( or a percentage smaller) to include in any forthcoming presentation of corelinux, that would be a mini logo 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-26 02:54:13
|
On Fri, 25 Aug 2000, you wrote: > You mean the last one on the page? No I mean the number 4 (the one before the last in logo.php page) C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | "It may be that our role on this Cambridge MA 02139 | planet is not to worship God but to Tel (Office) : (00 1) (617) 253 0229 | create him." Fax (Office) : (00 1) (617) 258 8559 | -Arthur C. Clarke http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-08-26 02:52:27
|
Ok, you mean #9 so thats Hans/Christophe for #9 So what do I need to tell the artist as far as format (png, eps,?), and opaque background? Christophe Prud'homme wrote: > > On Fri, 25 Aug 2000, you wrote: > > Christophe? > let's say #4 in logo.php page > > oo with the o of corelinux > ++ for c++ > and linux for,hum, [core]linux > > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | Man is the only animal that blushes > Cambridge MA 02139 | or needs to. > Tel (Office) : (00 1) (617) 253 0229 | -- Mark Twain > Fax (Office) : (00 1) (617) 258 8559 | > 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: Frank V. C. <fr...@co...> - 2000-08-26 02:50:35
|
You mean the last one on the page? Christophe Prud'homme wrote: > > On Fri, 25 Aug 2000, you wrote: > > Christophe? > let's say #4 in logo.php page > > oo with the o of corelinux > ++ for c++ > and linux for,hum, [core]linux > > -- > Christophe Prud'homme | > MIT, 77, Mass Ave, Rm 3-243 | Man is the only animal that blushes > Cambridge MA 02139 | or needs to. > Tel (Office) : (00 1) (617) 253 0229 | -- Mark Twain > Fax (Office) : (00 1) (617) 258 8559 | > 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-08-26 02:31:08
|
On Fri, 25 Aug 2000, you wrote: > Christophe? let's say #4 in logo.php page oo with the o of corelinux ++ for c++ and linux for,hum, [core]linux -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243 | Man is the only animal that blushes Cambridge MA 02139 | or needs to. Tel (Office) : (00 1) (617) 253 0229 | -- Mark Twain Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit |
|
From: Frank V. C. <fr...@co...> - 2000-08-26 02:07:12
|
Christophe? Hans Dulimarta wrote: > > "Frank V. Castellucci" wrote: > > > > Lets make a decision on the logo. > > > > I like #6 > > > > I like #9 (first priority) and #6 (second priority) > > > -- > > Frank V. Castellucci > > http://corelinux.sourceforge.net > > OOA/OOD/C++ Standards and Guidelines for Linux > > http://PythPat.sourceforge.net > > Pythons Pattern Package > > _______________________________________________ > > 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-26 01:11:56
|
"Frank V. Castellucci" wrote: > > Lets make a decision on the logo. > > I like #6 > I like #9 (first priority) and #6 (second priority) > -- > Frank V. Castellucci > http://corelinux.sourceforge.net > OOA/OOD/C++ Standards and Guidelines for Linux > http://PythPat.sourceforge.net > Pythons Pattern Package > _______________________________________________ > 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-25 22:28:23
|
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 |
|
From: Hans - D. <dul...@eg...> - 2000-08-25 18:35:00
|
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 |
|
From: Hans - D. <dul...@eg...> - 2000-08-25 16:19:39
|
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. > > > 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 |
|
From: Frank V. C. <fr...@co...> - 2000-08-25 11:55:58
|
Lets make a decision on the logo. I like #6 -- 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-25 11:41:02
|
I added the following to the BugManager categories: libclfw++ ( base abstract frameworks ) libclfwfl++ ( function library loader ) So, new abstraction features we accept go int libclfw++, and we create a new category for any extensions we implement. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
1115 messages has been excluded from this view by a project administrator.
