Once again, I find I need a binary semaphore for a C application I'm porting from another OS. The eCos kernel has binary semaphores, but there is only a C++ API and no C API. I and others have asked why there is no C API for binary semaphores, and all I've ever really understood of the answer was that certain developers didn't think binary semaphores were cool enough. I'm implementing a C API for binary semaphores. It'c completely trivial and consits of only a few dozen lines of code. Any chance such a patch would be accepted, or are binary semaphores still too uncool to sit at the same lunch table as mutexes and counting semaphores? -- Grant Edwards grant.b.edwards Yow! I smell like a wet at reducing clinic on Columbus gmail.com Day! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 16.03.2015 18:17, Grant Edwards wrote: > Once again, I find I need a binary semaphore for a C application I'm > porting from another OS. And just using a mutex is not a option? (Sorry if you allready ruled that out, but you didn't metion why youd need that specific sync-mechanism). Serafin -- Serafin Leschke, BSc in Computer Sience UAS Zurich Research Assistant ZHAW, Zurich University of Applied Sciences InES, Institute of Embedded Systems Postfach Technikumstr. 22 CH-8401 Winterthur -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 2015-03-17, lesc <lesc@zhaw.ch> wrote: > > > On 16.03.2015 18:17, Grant Edwards wrote: >> Once again, I find I need a binary semaphore for a C application I'm >> porting from another OS. > And just using a mutex is not a option? (Sorry if you allready ruled > that out, but you didn't metion why youd need that specific > sync-mechanism). The Semaphore is used so that one thread can wait for completion of a task that was farmed out to different thread: Thread A waits on the semaphore until thread B posts. It's an inter-thread signalling mechanism, not a mutual-exclusion mechansim. I'm not sure why a counting semaphore wasn't used by the applications author. I haven't analyzed all of the possible execution paths, but the original author of the application very specifically chose to use a binary semaphore instead of a counting semaphore, and it seemed wisest not to change things without a good reason. It took a half-hour to implement a C API for binary semaphores, it could take weeks to analyze tens of thousands lines of third-party code to see if a counting semaphore would work the same as a binary semaphore in all the corner cases. -- Grant Edwards grant.b.edwards Yow! I guess you guys got at BIG MUSCLES from doing too gmail.com much STUDYING! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On 2015-03-17, Grant Edwards <grant.b.edwards@gmail.com> wrote: > On 2015-03-17, lesc <lesc@zhaw.ch> wrote: >> >> >> On 16.03.2015 18:17, Grant Edwards wrote: >>> Once again, I find I need a binary semaphore for a C application I'm >>> porting from another OS. > >> And just using a mutex is not a option? (Sorry if you allready ruled >> that out, but you didn't metion why youd need that specific >> sync-mechanism). > > The Semaphore is used so that one thread can wait for completion of a > task that was farmed out to different thread: Thread A waits on the > semaphore until thread B posts. It's an inter-thread signalling > mechanism, not a mutual-exclusion mechansim. Perhaps I should be a bit more detailed: a Mutex is owned by the thread that calls cyg_mytex_lock(), and it can't be unlocked by a different thread. This enforcement of ownership prevents a mutex from being used in place of a binary semaphore for inter-thread signalling. I've run across situations in the past where I needed to use a semaphore for mutual exclusion, but a counting semaphore initialized to 1 works fine for that as long as you only release the resource once after acquiring it (not usually a problem). -- Grant Edwards grant.b.edwards Yow! World War III? at No thanks! gmail.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
I'm in agreement, for what it's worth. I've had to make use of the binary semaphore through the C++ API, and it always made me wonder why it wasn't brought out to the public/C API. Why code up the exact same thing with a condition variable when there's a perfectly good binary semaphore in the OS? Frank On 03/17/2015 10:47 AM, Grant Edwards wrote: > On 2015-03-17, Grant Edwards <grant.b.edwards@gmail.com> wrote: >> On 2015-03-17, lesc <lesc@zhaw.ch> wrote: >>> >>> On 16.03.2015 18:17, Grant Edwards wrote: >>>> Once again, I find I need a binary semaphore for a C application I'm >>>> porting from another OS. >>> And just using a mutex is not a option? (Sorry if you allready ruled >>> that out, but you didn't metion why youd need that specific >>> sync-mechanism). >> The Semaphore is used so that one thread can wait for completion of a >> task that was farmed out to different thread: Thread A waits on the >> semaphore until thread B posts. It's an inter-thread signalling >> mechanism, not a mutual-exclusion mechansim. > Perhaps I should be a bit more detailed: a Mutex is owned by the > thread that calls cyg_mytex_lock(), and it can't be unlocked by a > different thread. This enforcement of ownership prevents a mutex from > being used in place of a binary semaphore for inter-thread signalling. > > I've run across situations in the past where I needed to use a > semaphore for mutual exclusion, but a counting semaphore initialized > to 1 works fine for that as long as you only release the resource once > after acquiring it (not usually a problem). > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
On Tue, Mar 17, 2015 at 10:57:06AM -0400, Frank Pagliughi wrote: > I'm in agreement, for what it's worth. I've had to make use of the > binary semaphore through the C++ API, and it always made me wonder why > it wasn't brought out to the public/C API. I've been asking that for 15 years. OK, I exaggerate. I just looked itup and the first thread I started on this top was March 2001, so it's only been 14 years. The reason given for lack of a binary semaphore C API was: It was never intended that the KAPI be a complete reflection of the kernel implementation. It is meant to be a consistent, self-contained, small API that can be used by C applications. Like the uITRON and POSIX APIs it only exposes a subset. It was considered unnecessary to export binary semaphores, since a counting semaphore initialized to 1 is functionally equivalent. If I had had my way the KAPI would have been even more minimal that it currently is. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK Except a counting semaphore initialized to 1 is _not_ functionally equivalent to a binary semaphore in all cases. I pointed this out and provided examples of sequences of wait/post where the behavior differs, but was told those sequences were "bugs" and (jokingly, I hope) if I didn't shut up and stop asking questions then the C++ binary semaphores would be removed copletely. It was quite clear that Nick was adamantly opposed to providing a C API for binary semaphores and that the needs of eCos users' application code were to be overruled by his idea of what an comprised a minimal, complete, elegent set of C APIs: people who want to write/port C apps that use binary semaphores should just and rewrite the application code. IOW, all you really need are two-input NAND gates to model any Turing complete machine so stop bitching and get to work. -- Grant -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss