From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Sergei Organov Cc: bartv@redhat.com, nickg@redhat.com, ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] No binary semaphore in C API? Date: Wed, 28 Mar 2001 07:38:00 -0000 Message-id: <20010328093817.A1328@visi.com> References: <20010316140116.A1062@visi.com> <3AB67D44.AFB5E10D@redhat.com> <20010326133727.A3008@visi.com> <200103281329.f2SDT3b05686@sheesh.cambridge.redhat.com> <87u24ehs0d.fsf@osv.javad.ru> X-SW-Source: 2001-03/msg00490.html On Wed, Mar 28, 2001 at 06:45:06PM +0400, Sergei Organov wrote: > > Nick> I would say that binary semaphores mask the bug, rather that > > Nick> protect you. In the above example the second post() is just > > Nick> lost. With counting semaphores it has an effect, which you > > Nick> would hopefully pick up during testing. > > > > Arguably there should be an assert in Cyg_Binary_Semaphore::post(), > > > > CYG_ASSERT( false == state, "Posting to unlocked binary semaphore"); > > > > However I am not sure that there is sufficient agreement on the > > general semantics of binary semaphores to make that assertion > > valid. Some people might expect multiple posts to be a no-op. > > IMO the absence of completely clear semantics for a > > synchronization primitive is a good argument for removing that > > primitive completely. > > Sorry, but for me it seems that initial assumption -- using > semaphore for mutual exclusion -- is wrong, so the rest of > argumentation doesn't make much sense for me. Don't we have > mutexes for mutual exclusion? Just use mutexes and put > corresponding 'CYG_ASSERT' into mutex implementation if it is > not already there. I can't use a mutex because a mutex must be unlocked by the same thread that locked it. In my application the mutual exclusion is between two groups of threads. In each group of threads there is one thread that acquires the resource and then some time later a different thread releases it. One of the groups of threads is a legacy application and I don't have time to re-design it. [I've already got a legacy eCos app I'm trying to integrate into a newer eCos based system.] > Binary semaphores could be used for task synchronization when > their behavior fits better than those of two other light-weight > primitives, events (signals) and counting semaphores. To send > event one needs to know task id to send event to, and using > counting semaphore doesn't allow to get single wake-up after > multiple posts without additional logic. In my application multiple posts aren't supposed to happen, so if it does it's a bug. With counting semaphores the bug has noticable results. With a binary semaphore *where a second post is defined as noop* the bug is masked. OTOH, I think it could be easily argued that a post on a binary semaphore already in state 1 should be defined to be illegal or have undefined behavior. > Thus the binary semaphore combines two useful features of > events and counting semaphores in one primitive that makes it > pretty useful. > > This makes me feel that completely clear semantics for binary > semaphore does exist and matches its current semantics in the > eCos kernel, i.e., neither suggested 'CYG_ASSERT' nor removing > binary semaphore support are good ideas, IMHO. -- Grant Edwards grante@visi.com