|
From: Frank V. C. <fr...@co...> - 2000-09-10 03:12:28
|
Hans - Dulimarta wrote: > > On Sat, 9 Sep 2000, Frank V. Castellucci wrote: > > > Date: Sat, 09 Sep 2000 18:33:18 -0400 > > From: Frank V. Castellucci <fr...@co...> > > Reply-To: cor...@li... > > To: cor...@li... > > Subject: Re: [Corelinux-develop] ChangeLog and Feature/Defect fixes > > > > Ok, couple of things: > > > > 1. I change the listener counters in EventSemaphore to type Counter > > (which is signed) from Count (which is unsigned). > > I did not know we have both Count and Counter. Yes, the compiler was warning that the comparison of Count always results in true because >= 0 > > > 2. I wrapped the include <sys/sem.h> in extern "C" > > > > So the code looks good there, but, question, and if you already answered > > this I'm sorry: > > > > Given the scenario where I have two listeners and (obviously) one > > controller > > > > 1. The controller creates the semaphore and it is locked > > 2. The listeners come in and block on the wait (wait(0)) > > 3. The controller releases the semaphore > > 4. The listeners, in a tight loop, come right back in and try to block > > again > > > > Because the controller has released but not regained the control (-1), > > this will mean that the listeners will behave as though they got another > > event, while in actuality they haven't, correct? > > > > You are correct. > > What respond should the listener get when it try to block on unlock > semaphore. Yes, this is not an easy answer. My first thought is to keep a queue state indicators which increased for each thread entering a blocked state, and decrements it for each one going out, zero resulting in a state indication that all waiting threads have been serviced. The last one out (last listener that causes zero state indicator) closes the door (sets semaphore value to (-1) again). The use of monitors around this activity will insure that the queue state indiciators are kept properly. That way, attempts to come back in and listen before all threads have been serviced can return UNAVAILABLE until which point you block. Thoughts? > > > > > Hans - Dulimarta wrote: > > > > > > On Sat, 9 Sep 2000, Frank V. Castellucci wrote: > > > > > > > Date: Sat, 09 Sep 2000 07:56:55 -0400 > > > > From: Frank V. Castellucci <fr...@co...> > > > > Reply-To: cor...@li... > > > > To: CoreLinux Development <cor...@li...> > > > > Subject: [Corelinux-develop] ChangeLog and Feature/Defect fixes > > > > > > > > I have started marking defects/features "Closed" with appropriate > > > > resolution as they are handled. I am keeping ChangeLog up-to-date on a > > > > regular basis. > > > > > > > > This will reduce the amount of work required at release time, which has > > > > grown exponentially between packages and the SourceForge changes (ugh). > > > > > > > > > > I have checked in EventSemaphore and EventSemaphoreGroup, but not the test > > > suite. Frank, I need your help to write an example/test code. > > > > > > Also, I fixed the bug 113103 by declaring the struct semun when > > > _SEM_SEMUN_UNDEFINED_ is defined. I have tested using egcs-1.1.2 on my > > > RedHat 6.2. The bug submitter compiled the code under Debian 2.1. I hope > > > it does not make any difference. > > > > > > -- > > > 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 |