|
From: Hans - D. <dul...@eg...> - 2000-09-10 04:39:22
|
On Sat, 9 Sep 2000, Frank V. Castellucci wrote: > Date: Sat, 09 Sep 2000 23:15:14 -0400 > From: Frank V. Castellucci <fr...@co...> > Reply-To: cor...@li... > To: cor...@li... > Subject: Re: [Corelinux-develop] ChangeLog and Feature/Defect fixes > > 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 Which compiler are you using? My egcs-1.1.2 did not give me this warning message. > > > > > > 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? > POSIX semaphores have queues somewhere in their implementation. I guess we can take advantage of this and don't have to provide our own queue. The 'theNumListeners' data member, I guess, resembles the "queue state indicator" you mentioned above. When a listener is being block, it will stay inside "waitZero()". So, the last listeners being freed from waitZero() can be identified by decrementing theNumListeners after returning waitZero(). > > > > > > > > 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 > > -- 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 |