* [ECOS] No binary semaphore in C API? @ 2001-03-16 12:01 Grant Edwards 2001-03-19 13:42 ` Jonathan Larmour 0 siblings, 1 reply; 23+ messages in thread From: Grant Edwards @ 2001-03-16 12:01 UTC (permalink / raw) To: ecos-discuss Hi all, I see that the kernel impliments binary semaphores, but I can't see a C API for them. I've got a mutual-exclusion requirement but can't use cyg_mutex_t because one thread locks and a different thread unlocks the resource. [It's kind of complicated, the mutal exclusion is between two "groups" of threads.] So, I wanted to use binary semaphores, but can't find the API. The program is using counting semaphores right now, but using a binary ones would be a bit more "defensive". Is there a technical reason that there isn't a C API for binary semaphores, or is it something that just hasn't been done yet? -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-16 12:01 [ECOS] No binary semaphore in C API? Grant Edwards @ 2001-03-19 13:42 ` Jonathan Larmour 2001-03-26 3:53 ` Nick Garnett 0 siblings, 1 reply; 23+ messages in thread From: Jonathan Larmour @ 2001-03-19 13:42 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss, Nick Garnett Grant Edwards wrote: > > So, I wanted to use binary semaphores, but can't find the API. > The program is using counting semaphores right now, but using a > binary ones would be a bit more "defensive". > > Is there a technical reason that there isn't a C API for binary > semaphores, or is it something that just hasn't been done yet? Certainly no technical reason. Nick may not have done it out of principle. But right now he's on vacation, so it's best to wait till he returns. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-19 13:42 ` Jonathan Larmour @ 2001-03-26 3:53 ` Nick Garnett 2001-03-26 7:12 ` Fabrice Gautier 2001-03-26 11:37 ` Grant Edwards 0 siblings, 2 replies; 23+ messages in thread From: Nick Garnett @ 2001-03-26 3:53 UTC (permalink / raw) To: ecos-discuss Jonathan Larmour <jlarmour@redhat.com> writes: > Grant Edwards wrote: > > > > So, I wanted to use binary semaphores, but can't find the API. > > The program is using counting semaphores right now, but using a > > binary ones would be a bit more "defensive". > > > > Is there a technical reason that there isn't a C API for binary > > semaphores, or is it something that just hasn't been done yet? > > Certainly no technical reason. Nick may not have done it out of principle. > But right now he's on vacation, so it's best to wait till he returns. > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-26 3:53 ` Nick Garnett @ 2001-03-26 7:12 ` Fabrice Gautier 2001-03-26 11:37 ` Grant Edwards 1 sibling, 0 replies; 23+ messages in thread From: Fabrice Gautier @ 2001-03-26 7:12 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss On 26 Mar 2001 12:39:07 +0100 Nick Garnett <nickg@cygnus.co.uk> wrote: > > It was never intended that the KAPI be a complete reflection of the > kernel implementation. [...] > If I had had my way the KAPI would have been even more minimal that it > currently is. Aahhh... Is that why my (quite old now) patch implementing the C KAPI for the clock conversion functions was never included in the official tree ? (Well, maybe it is now, havent look at it too closely recently) Nevermind anyway,... A+ -- Fabrice Gautier <gautier@email.enstfr> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-26 3:53 ` Nick Garnett 2001-03-26 7:12 ` Fabrice Gautier @ 2001-03-26 11:37 ` Grant Edwards 2001-03-27 2:00 ` Nick Garnett 1 sibling, 1 reply; 23+ messages in thread From: Grant Edwards @ 2001-03-26 11:37 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss On Mon, Mar 26, 2001 at 12:39:07PM +0100, Nick Garnett wrote: > > > Is there a technical reason that there isn't a C API for binary > > > semaphores, or is it something that just hasn't been done yet? > > > > Certainly no technical reason. Nick may not have done it out of > > principle. But right now he's on vacation, so it's best to wait > > till he returns. > > 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, Why impliment binary semaphores if there is no intent to allow their use? > since a counting semaphore initialized to 1 is functionally > equivalent. Not quite. There are sequences of wait()/post() that will not give the same results for an boolean and integer semaphore. Task 1 Task 2 ------ ------ [semaphore value == 1] wait() post() post() wait() wait() At this point, only one of the tasks is runnable with binary semaphores, but both are runnable with a counting semaphore. Admittedly, multiple posts is probably a bug if you intend the semaphore to be used for mutual exclusion, but using a binary semaphore protects you from such bugs. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-26 11:37 ` Grant Edwards @ 2001-03-27 2:00 ` Nick Garnett 2001-03-27 5:32 ` Grant Edwards 2001-03-28 5:29 ` Bart Veer 0 siblings, 2 replies; 23+ messages in thread From: Nick Garnett @ 2001-03-27 2:00 UTC (permalink / raw) To: ecos-discuss Grant Edwards <grante@visi.com> writes: > On Mon, Mar 26, 2001 at 12:39:07PM +0100, Nick Garnett wrote: > > > > > Is there a technical reason that there isn't a C API for binary > > > > semaphores, or is it something that just hasn't been done yet? > > > > > > Certainly no technical reason. Nick may not have done it out of > > > principle. But right now he's on vacation, so it's best to wait > > > till he returns. > > > > 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, > > Why impliment binary semaphores if there is no intent to > allow their use? They are available from C++. Binary semaphores were one of the first synchronization primitives I implemented. It happens that none of the APIs use them, so they are somewhat redundant. I could always remove them if that would make you happier :-) > > > since a counting semaphore initialized to 1 is functionally > > equivalent. > > Not quite. There are sequences of wait()/post() that will not > give the same results for an boolean and integer semaphore. > > Task 1 Task 2 > ------ ------ > [semaphore value == 1] > wait() > post() > post() > wait() wait() > > At this point, only one of the tasks is runnable with binary > semaphores, but both are runnable with a counting semaphore. > > Admittedly, multiple posts is probably a bug if you intend the > semaphore to be used for mutual exclusion, but using a binary > semaphore protects you from such bugs. > I would say that binary semaphores mask the bug, rather that protect you. In the above example the second post() is just lost. With counting semaphores it has an effect, which you would hopefully pick up during testing. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-27 2:00 ` Nick Garnett @ 2001-03-27 5:32 ` Grant Edwards 2001-03-28 5:29 ` Bart Veer 1 sibling, 0 replies; 23+ messages in thread From: Grant Edwards @ 2001-03-27 5:32 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss On Tue, Mar 27, 2001 at 10:46:18AM +0100, Nick Garnett wrote: > > Why impliment binary semaphores if there is no intent to > > allow their use? > > They are available from C++. Binary semaphores were one of the first > synchronization primitives I implemented. It happens that none of the > APIs use them, so they are somewhat redundant. I could always remove > them if that would make you happier :-) Sure -- then I don't have to be jealous. Counting semaphores are working just fine, but I was curious. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-27 2:00 ` Nick Garnett 2001-03-27 5:32 ` Grant Edwards @ 2001-03-28 5:29 ` Bart Veer 2001-03-28 6:45 ` Sergei Organov 2001-03-29 11:55 ` Chris Gray 1 sibling, 2 replies; 23+ messages in thread From: Bart Veer @ 2001-03-28 5:29 UTC (permalink / raw) To: nickg; +Cc: ecos-discuss >>>>> "Nick" == Nick Garnett <nickg@cambridge.redhat.com> writes: <snip> >> > since a counting semaphore initialized to 1 is functionally >> > equivalent. >> >> Not quite. There are sequences of wait()/post() that will not >> give the same results for an boolean and integer semaphore. >> >> Task 1 Task 2 >> ------ ------ >> [semaphore value == 1] >> wait() >> post() >> post() >> wait() wait() >> >> At this point, only one of the tasks is runnable with binary >> semaphores, but both are runnable with a counting semaphore. >> >> Admittedly, multiple posts is probably a bug if you intend the >> semaphore to be used for mutual exclusion, but using a binary >> semaphore protects you from such bugs. 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. Bart ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 5:29 ` Bart Veer @ 2001-03-28 6:45 ` Sergei Organov 2001-03-28 7:38 ` Grant Edwards 2001-03-28 7:39 ` Bart Veer 2001-03-29 11:55 ` Chris Gray 1 sibling, 2 replies; 23+ messages in thread From: Sergei Organov @ 2001-03-28 6:45 UTC (permalink / raw) To: bartv; +Cc: nickg, ecos-discuss Bart Veer <bartv@redhat.com> writes: > >>>>> "Nick" == Nick Garnett <nickg@cambridge.redhat.com> writes: > > <snip> > > >> > since a counting semaphore initialized to 1 is functionally > >> > equivalent. > >> > >> Not quite. There are sequences of wait()/post() that will not > >> give the same results for an boolean and integer semaphore. > >> > >> Task 1 Task 2 > >> ------ ------ > >> [semaphore value == 1] > >> wait() > >> post() > >> post() > >> wait() wait() > >> > >> At this point, only one of the tasks is runnable with binary > >> semaphores, but both are runnable with a counting semaphore. > >> > >> Admittedly, multiple posts is probably a bug if you intend the > >> semaphore to be used for mutual exclusion, but using a binary > >> semaphore protects you from such bugs. > > 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. 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. 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. Sergei. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 6:45 ` Sergei Organov @ 2001-03-28 7:38 ` Grant Edwards 2001-03-28 7:39 ` Bart Veer 1 sibling, 0 replies; 23+ messages in thread From: Grant Edwards @ 2001-03-28 7:38 UTC (permalink / raw) To: Sergei Organov; +Cc: bartv, nickg, ecos-discuss 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 6:45 ` Sergei Organov 2001-03-28 7:38 ` Grant Edwards @ 2001-03-28 7:39 ` Bart Veer 2001-03-28 10:01 ` Sergei Organov 2001-03-28 10:01 ` Jonathan Larmour 1 sibling, 2 replies; 23+ messages in thread From: Bart Veer @ 2001-03-28 7:39 UTC (permalink / raw) To: osv; +Cc: ecos-discuss >>>>> "Sergei" == Sergei Organov <osv@javad.ru> writes: <snip> >> 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. Sergei> Sorry, but for me it seems that initial assumption -- Sergei> using semaphore for mutual exclusion -- is wrong, so the Sergei> rest of argumentation doesn't make much sense for me. Sergei> Don't we have mutexes for mutual exclusion? Just use Sergei> mutexes and put corresponding 'CYG_ASSERT' into mutex Sergei> implementation if it is not already there. The original posting, http://sources.redhat.com/ml/ecos-discuss/2001-03/msg00250.html described why a binary semaphore was being used rather than a mutex. "I've got a mutual-exclusion requirement but can't use cyg_mutex_t because one thread locks and a different thread unlocks the resource. [It's kind of complicated, the mutal exclusion is between two "groups" of threads.]" In that context the assertion would be correct. You describe a different use for binary semaphores where the assertion would be incorrect. Hence there is confusion about semantics, which is pretty disastrous for a synchronization primitive. Arguably the better alternative would be to implement a new mutex class which deals with thread groups, rather than overloading binary semaphores. The latter could then be left with their existing semantics, although people might still be confused and use them incorrectly for mutual exclusion. Bart ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 7:39 ` Bart Veer @ 2001-03-28 10:01 ` Sergei Organov 2001-03-28 11:05 ` Grant Edwards 2001-03-28 10:01 ` Jonathan Larmour 1 sibling, 1 reply; 23+ messages in thread From: Sergei Organov @ 2001-03-28 10:01 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss Bart Veer <bartv@redhat.com> writes: > >>>>> "Sergei" == Sergei Organov <osv@javad.ru> writes: > > <snip> > > >> 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. > > Sergei> Sorry, but for me it seems that initial assumption -- > Sergei> using semaphore for mutual exclusion -- is wrong, so the > Sergei> rest of argumentation doesn't make much sense for me. > Sergei> Don't we have mutexes for mutual exclusion? Just use > Sergei> mutexes and put corresponding 'CYG_ASSERT' into mutex > Sergei> implementation if it is not already there. > > The original posting, > http://sources.redhat.com/ml/ecos-discuss/2001-03/msg00250.html > described why a binary semaphore was being used rather than a mutex. > > "I've got a mutual-exclusion requirement but can't use cyg_mutex_t > because one thread locks and a different thread unlocks the > resource. [It's kind of complicated, the mutal exclusion is between > two "groups" of threads.]" > I didn't try to solve initial poster's problem, -- I tried to argue against changes in binary semaphore semantics. My apologies if it was not clear from my post. > In that context the assertion would be correct. Yes, I see, but attempt was made to make general decisions about semantics of binary semaphore based on its incorrect use. Every primitive could be used incorrectly, -- this doesn't mean its semantics is unclear. > You describe a different use for binary semaphores where the assertion would > be incorrect. Yes, and I think that unlike initial poster I described correct use for binary semaphore. If there are two possible semantics one of which is useful for invalid use and another is useful for valid use, which one is preferred? For me the answer is clear. > Hence there is confusion about semantics, which is pretty disastrous for a > synchronization primitive. The key word here is "synchronization", I think. Using synchronization primitive for mutual exclusion is a mistake no matter which synchronization primitive is used. This has nothing to do with semantics of binary semaphore, I'm afraid. For example, the same way I can try to prove that mutex has confusing semantics: "I've tried to use it for task synchronization but that didn't work as expected" ;-) Didn't you hear about guys that try to lock mutex from one thread and then unlock it from another? I heard it many times, but nobody wants to remove mutexes or change their semantics because of this. I believe that once semantics is documented, there should be no confusion about it. And the only semantics that seems to be reasonable for binary semaphore is the current one. > > Arguably the better alternative would be to implement a new mutex > class which deals with thread groups, rather than overloading > binary semaphores. Exactly. > The latter could then be left with their existing semantics, although people > might still be confused and use them incorrectly for mutual exclusion. Yes, somebody will be confused no matter what. But again this is true for every primitive. For example, sometimes people are confused by the fact that sending two events may result in single wake-up. Does it make events semantics confusing? Is it a cause to change events semantics or remove their support? How it is different from binary semaphores? Sergei, BinarySemaphoreGuard. :-) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 10:01 ` Sergei Organov @ 2001-03-28 11:05 ` Grant Edwards 2001-03-29 11:51 ` Sergei Organov 0 siblings, 1 reply; 23+ messages in thread From: Grant Edwards @ 2001-03-28 11:05 UTC (permalink / raw) To: Sergei Organov; +Cc: bartv, ecos-discuss On Wed, Mar 28, 2001 at 10:01:11PM +0400, Sergei Organov wrote: > Yes, I see, but attempt was made to make general decisions > about semantics of binary semaphore based on its incorrect use. What incorrect use is that? > Every primitive could be used incorrectly, -- this doesn't mean > its semantics is unclear. > > > You describe a different use for binary semaphores where the > > assertion would be incorrect. > > Yes, and I think that unlike initial poster I described correct > use for binary semaphore. Are you saying that using semaphores for mutual exlcusion is an "incorrect" usage? According the OS text we used (many years ago), mutual exclusions was one ot standard uses for semaphores. > > Hence there is confusion about semantics, which is pretty > > disastrous for a synchronization primitive. > > The key word here is "synchronization", I think. Using > synchronization primitive for mutual exclusion is a mistake no > matter which synchronization primitive is used. Your usage of "mutal exclusion" vs. "synchronization" is new to me. I was taught that mutual exclusion is one type of synchronization. What's your definition of "synchronization"? > This has nothing to do with semantics of binary semaphore, I'm > afraid. For example, the same way I can try to prove that mutex > has confusing semantics: "I've tried to use it for task > synchronization but that didn't work as expected" ;-) Didn't > you hear about guys that try to lock mutex from one thread and > then unlock it from another? I heard it many times, but nobody > wants to remove mutexes or change their semantics because of > this. > > I believe that once semantics is documented, there should be no > confusion about it. And the only semantics that seems to be > reasonable for binary semaphore is the current one. I also think that once you decide what to do about post() on a true-valued semaphore, the semantics for a binary semphore are not ambiguous or confusing at all. Either a second post() is a noop, or it's not allowed. > > Arguably the better alternative would be to implement a new > > mutex class which deals with thread groups, rather than > > overloading binary semaphores. I don't see how this is "overloading" a binary semaphore. I thought that mutual exclusion was one of the primary uses for which binary semaphores were intended. > > The latter could then be left with their existing semantics, > > although people might still be confused and use them > > incorrectly for mutual exclusion. Again, why is it incorrect to use a binary semaphor for mutual exclusion? FWIW, that's how I was taught to do mutual exclusion. Way back when, all we had were semaphores (binary or counting), and we got along just fine. ;) Both of the RTOS kernels I designed had nothing other than binary semaphores for mutual exclusion, and everybody seemed happy. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 11:05 ` Grant Edwards @ 2001-03-29 11:51 ` Sergei Organov 2001-03-29 11:49 ` Grant Edwards 0 siblings, 1 reply; 23+ messages in thread From: Sergei Organov @ 2001-03-29 11:51 UTC (permalink / raw) To: Grant Edwards; +Cc: bartv, ecos-discuss Grant Edwards <grante@visi.com> writes: > On Wed, Mar 28, 2001 at 10:01:11PM +0400, Sergei Organov wrote: > > > Yes, I see, but attempt was made to make general decisions > > about semantics of binary semaphore based on its incorrect use. > > What incorrect use is that? Sorry, maybe my wording is not exact once again :-( It's not invalid in the weak sense of the word, i.e., program that uses them for mutual exclusion is not necessarily invalid. But I believe that it's somewhat invalid use as the only primitive that is designed for mutual exclusion in reasonably recently developed systems is mutex. > > > Every primitive could be used incorrectly, -- this doesn't mean > > its semantics is unclear. > > > > > You describe a different use for binary semaphores where the > > > assertion would be incorrect. > > > > Yes, and I think that unlike initial poster I described correct > > use for binary semaphore. > > Are you saying that using semaphores for mutual exlcusion is > an "incorrect" usage? According the OS text we used (many > years ago), mutual exclusions was one ot standard uses for > semaphores. Yes. Since mutexes were invented, semaphores shouldn't be used for mutual exclusion anymore, I believe. I'm aware that some time ago binary semaphores were being used for mutual exclusion and some people are used to it. Maybe that's the primary source of confusion about usage of binary semaphores. > > > > Hence there is confusion about semantics, which is pretty > > > disastrous for a synchronization primitive. > > > > The key word here is "synchronization", I think. Using > > synchronization primitive for mutual exclusion is a mistake no > > matter which synchronization primitive is used. > > Your usage of "mutal exclusion" vs. "synchronization" is new to > me. I was taught that mutual exclusion is one type of > synchronization. What's your definition of "synchronization"? Well, this is just terminology. I prefer to don't consider mutual exclusion a kind of synchronization as they have different aims. The aim of mutual exclusion is disallowing simultaneous access to a shared resource, while the aim of synchronization is, well, to synchronize task activities. Such approach just seems to be clearer to me and leads to less confusion, I believe. It also seems to be more reasonable as different primitives are currently used for these two purposes. Though my opinion could be expressed using your terminology as well: "Use mutexes for mutual exclusion and other primitives for other kinds of synchronization." > > > This has nothing to do with semantics of binary semaphore, I'm > > afraid. For example, the same way I can try to prove that mutex > > has confusing semantics: "I've tried to use it for task > > synchronization but that didn't work as expected" ;-) Didn't > > you hear about guys that try to lock mutex from one thread and > > then unlock it from another? I heard it many times, but nobody > > wants to remove mutexes or change their semantics because of > > this. > > > > I believe that once semantics is documented, there should be no > > confusion about it. And the only semantics that seems to be > > reasonable for binary semaphore is the current one. > > I also think that once you decide what to do about post() on a > true-valued semaphore, the semantics for a binary semphore are > not ambiguous or confusing at all. Either a second post() is a > noop, or it's not allowed. > > > > Arguably the better alternative would be to implement a new > > > mutex class which deals with thread groups, rather than > > > overloading binary semaphores. > > I don't see how this is "overloading" a binary semaphore. I > thought that mutual exclusion was one of the primary uses for > which binary semaphores were intended. > > > > The latter could then be left with their existing semantics, > > > although people might still be confused and use them > > > incorrectly for mutual exclusion. Historically, yes. But currently old binary semaphores are called "mutexes", I believe, and current binary semaphores just lost their initial purpose to be used for mutual exclusion. > > Again, why is it incorrect to use a binary semaphor for mutual > exclusion? FWIW, that's how I was taught to do mutual > exclusion. Way back when, all we had were semaphores (binary > or counting), and we got along just fine. ;) Both of the RTOS > kernels I designed had nothing other than binary semaphores for > mutual exclusion, and everybody seemed happy. As I already answered above, I consider using binary semaphores for mutual exclusion a mistake for those systems where mutexes exist. For those old systems where binary semaphores are designed for mutual exclusion there is no other choice than to use them. For their intended usage old binary semaphores are similar to newer mutexes. If everybody seemed happy with binary semaphores for mutual exclusion, why do you think mutexes were invented after all? Finally, all the above obviously is just my own understanding of the problem and it could be the case that it has nothing to do with reality at all. BR, Sergei, BinSemGuard. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-29 11:51 ` Sergei Organov @ 2001-03-29 11:49 ` Grant Edwards 0 siblings, 0 replies; 23+ messages in thread From: Grant Edwards @ 2001-03-29 11:49 UTC (permalink / raw) To: Sergei Organov; +Cc: bartv, ecos-discuss On Thu, Mar 29, 2001 at 11:39:12AM +0400, Sergei Organov wrote: > > On Wed, Mar 28, 2001 at 10:01:11PM +0400, Sergei Organov wrote: > > > > > Yes, I see, but attempt was made to make general decisions > > > about semantics of binary semaphore based on its incorrect use. > > > > What incorrect use is that? > > Sorry, maybe my wording is not exact once again :-( It's not > invalid in the weak sense of the word, i.e., program that uses > them for mutual exclusion is not necessarily invalid. But I > believe that it's somewhat invalid use as the only primitive > that is designed for mutual exclusion in reasonably recently > developed systems is mutex. So semaphores not only have defined semantics, but defined things you're allowed to do in a program using those semantics? That seems a bit odd. That's like saying "you're allowed to use integer math to count blue widgets but not orange widgets." > > > Every primitive could be used incorrectly, -- this doesn't mean > > > its semantics is unclear. How can a primitive use be use incorrect if you are using the defined semantics to accomplish a goal? I can see a usage as being incorrect if it depends on undefined behavior or platform-dependant side-effects. > > Are you saying that using semaphores for mutual exlcusion is an > > "incorrect" usage? According the OS text we used (many years > > ago), mutual exclusions was one ot standard uses for > > semaphores. > > Yes. Since mutexes were invented, semaphores shouldn't be used > for mutual exclusion anymore, I believe. Can you explain why do you believe that? Binary semaphores have defined semantics. The semantics for binary semaphores are those of mutual exclusion. Mutual exclusion is what binary semaphores do. If you don't use binary semaphores for mutual exclusion, what is the correct usage? What is the difference between a mutex and a binary semaphore? The only one I can see in a quick glance at the sources is that a mutex has to be unlocked by the same thread that locked it. Othewise they are the same thing. > I'm aware that some time ago binary semaphores were being used > for mutual exclusion and some people are used to it. Maybe > that's the primary source of confusion about usage of binary > semaphores. They still are. They just changed the spelling from "binary semaphore" to "mutex". ;) > > Your usage of "mutal exclusion" vs. "synchronization" is new to > > me. I was taught that mutual exclusion is one type of > > synchronization. What's your definition of "synchronization"? > > Well, this is just terminology. Yup. > I prefer to don't consider mutual exclusion a kind of > synchronization as they have different aims. The aim of mutual > exclusion is disallowing simultaneous access to a shared > resource, I consider that synchronization. You're trying to control the states of tasks over time with respect to each other. > while the aim of synchronization is, well, to synchronize task > activities. Like making sure that they don't try to do a certain thing at the same time? :) > Such approach just seems to be clearer to me and leads to less > confusion, I believe. It also seems to be more reasonable as > different primitives are currently used for these two purposes. > Though my opinion could be expressed using your terminology as > well: "Use mutexes for mutual exclusion and other primitives > for other kinds of synchronization." OK, if we change mutexes so that they can be unlocked by a thread different than the on that did the lock, what is the difference in semantics between a binary semaphore and a mutex? As far as I can tell, they are identical. > Historically, yes. But currently old binary semaphores are > called "mutexes", I believe, and current binary semaphores just > lost their initial purpose to be used for mutual exclusion. So it's OK to use a binary semaphore for mutual exclusion as long as you spell it "mutex" and not "binary semaphore." BTW, what is the difference between an "old binary semaphore" (now called a mutex) and a "current binary semaphore"? > As I already answered above, I consider using binary semaphores > for mutual exclusion a mistake for those systems where mutexes > exist. For those old systems where binary semaphores are > designed for mutual exclusion there is no other choice than to > use them. For their intended usage old binary semaphores are > similar to newer mutexes. > > If everybody seemed happy with binary semaphores for mutual > exclusion, why do you think mutexes were invented after all? Frankly, I can't see that mutexes are anything different than binary semaphores, so I don't know how one could claim to have "invented" mutexes. Prior art and all that. Perhaps I haven't looked at the internals enough, but the invention of the "mutex" seems to be mainly a change in spelling of the function name. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 7:39 ` Bart Veer 2001-03-28 10:01 ` Sergei Organov @ 2001-03-28 10:01 ` Jonathan Larmour 1 sibling, 0 replies; 23+ messages in thread From: Jonathan Larmour @ 2001-03-28 10:01 UTC (permalink / raw) To: bartv; +Cc: osv, ecos-discuss Bart Veer wrote: > > Arguably the better alternative would be to implement a new mutex > class which deals with thread groups, rather than overloading > binary semaphores. The latter could then be left with their existing > semantics, although people might still be confused and use them > incorrectly for mutual exclusion. Why don't we just make a CDL variable controlling which behaviour you get, with the failsafe assert version the default? That way the behaviour is implementation defined, not undefined. Personally I think binary semaphores are a useful paradigm, *complementary* to other sync primitives. I think it's better to provide a useful toolkit than try to enforce personal preferences about the way to write multi-threaded code. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-28 5:29 ` Bart Veer 2001-03-28 6:45 ` Sergei Organov @ 2001-03-29 11:55 ` Chris Gray 2001-03-29 19:33 ` Bart Veer 1 sibling, 1 reply; 23+ messages in thread From: Chris Gray @ 2001-03-29 11:55 UTC (permalink / raw) To: bartv; +Cc: nickg, ecos-discuss Bart Veer wrote: > 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. As I understand it, the theoretical semantics of a binary semaphore is that you "cannot" post to it twice. To the theoretician, the question of what happens when something that can't happen happens is purely hypothetical. In the system I'm currently working on (which uses ThreadX, but may one day move to eCos), we have a macro assertSemaphore which is most often used in the form "assertSemaphore(&s,1)" -- in other words to check that binary semaphore semantics are being respected. So maybe such an optional runtime check is all you need to add to counting semaphores to make them usable as binary ones. Regards Chris ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-29 11:55 ` Chris Gray @ 2001-03-29 19:33 ` Bart Veer 2001-03-29 20:50 ` Grant Edwards 2001-03-30 2:22 ` Sergei Organov 0 siblings, 2 replies; 23+ messages in thread From: Bart Veer @ 2001-03-29 19:33 UTC (permalink / raw) To: ecos-discuss >>>>> "Chris" == Chris Gray <gray@acunia.com> writes: Chris> Bart Veer wrote: >> 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. Chris> As I understand it, the theoretical semantics of a binary Chris> semaphore is that you "cannot" post to it twice. To the Chris> theoretician, the question of what happens when something Chris> that can't happen happens is purely hypothetical. Maybe it is time to look at some history. Looking at a 15-year old copy of an OS reference book, Peterson and Silberschatz, it describes the use of semaphores for mutual exclusion. However there are some problems with this use: most importantly a semaphore does not have the concept of a current owner thread, so the system can do nothing about priority inversion problems. Hence the introduction of a new primitive, the mutex, for mutual exclusion. Semaphores are still very useful, but as a means of communicating information between threads rather than for mutual exclusion. The original posting that started this thread involved a scenario where a mutex could not be used for mutual exclusion, so a binary semaphore was substituted instead. A side effect of this is that the system cannot help avoid priority inversion problems, so that will have to be addressed at the application level. For mutual exclusion usage, you need to worry about what happens if the application incorrectly executes a sequence lock/unlock/unlock/lock. IMO this should result in an assertion failure inside the second unlock, to facilitate tracking down the problem. Sergei described an alternative usage of binary semaphores as a synchronization primitive, for communication between threads: basically a way of informing other threads that some event has happened at least once. For this usage multiple posts to a binary semaphore should be equivalent to a single post, i.e. there is no difference in behaviour between wait/post/wait and wait/post/post/wait. For this usage, the assertion would be incorrect. Now, I am not entirely convinced that this use of binary semaphores is a good idea. Specifically, consider the sequences of events wait/post/post/wait and wait/post/wait/post, where the waits and the posts happen in different threads and are not otherwise synchronized. Depending on very subtle timing differences, e.g. when the thread doing the posts gets timesliced, both sequences are equally likely to happen but the resulting behaviour would be very different. I am somewhat uncomfortable with a synchronization primitive that can lead to such non-deterministic behaviour. The current binary semaphore implementation does not have the assertion, so it is not the best solution for mutual exclusion. That argues for a new class, e.g. Cyg_UnownedMutex, to serve that purpose. The Cyg_Binary_Semaphore class could then be left as is, i.e. behaving as per Sergei's event signalling usage. That could still confuse people who are used to thinking about binary semaphores as a legal mutual exclusion primitive, as per old reference titles. To avoid that we could also rename Cyg_Binary_Semaphore to something else, breaking the historical association. I am not sure anybody would be happy with this solution. Bart ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-29 19:33 ` Bart Veer @ 2001-03-29 20:50 ` Grant Edwards 2001-03-30 2:22 ` Sergei Organov 1 sibling, 0 replies; 23+ messages in thread From: Grant Edwards @ 2001-03-29 20:50 UTC (permalink / raw) To: Bart Veer; +Cc: ecos-discuss On Thu, Mar 29, 2001 at 12:18:40PM +0100, Bart Veer wrote: > Now, I am not entirely convinced that this use of binary semaphores is > a good idea. Specifically, consider the sequences of events > wait/post/post/wait and wait/post/wait/post, where the waits and the > posts happen in different threads and are not otherwise synchronized. > Depending on very subtle timing differences, e.g. when the thread > doing the posts gets timesliced, both sequences are equally likely to > happen but the resulting behaviour would be very different. I am > somewhat uncomfortable with a synchronization primitive that can lead > to such non-deterministic behaviour. The same problem arises with almost any synchronization primitive. Consider a mutex: if two threads do a lock() at the "same" time, a tiny change in timing alters which task obtains the resource -- resulting in a possibly large change in program behavior for an infinitely small change in timing. The behavior of systems with unsychronized inputs is like that. > The current binary semaphore implementation does not have the > assertion, so it is not the best solution for mutual > exclusion. That argues for a new class, e.g. Cyg_UnownedMutex, > to serve that purpose. The Cyg_Binary_Semaphore class could > then be left as is, i.e. behaving as per Sergei's event > signalling usage. That could still confuse people who are used > to thinking about binary semaphores as a legal mutual > exclusion primitive, as per old reference titles. To avoid > that we could also rename Cyg_Binary_Semaphore to something > else, breaking the historical association. Since the binary semaphore isn't exported as part of the kernel's C api, it's largely a moot question. :) -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-29 19:33 ` Bart Veer 2001-03-29 20:50 ` Grant Edwards @ 2001-03-30 2:22 ` Sergei Organov 2001-03-30 6:54 ` Grant Edwards 1 sibling, 1 reply; 23+ messages in thread From: Sergei Organov @ 2001-03-30 2:22 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss Bart Veer <bartv@redhat.com> writes: [...] > Maybe it is time to look at some history. > > Looking at a 15-year old copy of an OS reference book, Peterson and > Silberschatz, it describes the use of semaphores for mutual exclusion. > However there are some problems with this use: most importantly a > semaphore does not have the concept of a current owner thread, so the > system can do nothing about priority inversion problems. Hence the > introduction of a new primitive, the mutex, for mutual exclusion. > Semaphores are still very useful, but as a means of communicating > information between threads rather than for mutual exclusion. Exactly. I started to write my own explanation of differences, but you already explained it perfectly. The only thing that I'd like to make more explicit is that having owner concept not only makes provision for implementing of priority inheritance, but also is a good thing by itself as unlocking mutex by non-owner is explicitly prohibited. It's like bathroom door lock, -- once you entered the bathroom and locked the door, nobody else can enter until you unlock it, -- that's what mutual exclusion is about. Using binary semaphore for mutual exclusion resembles using of bathroom lock that is easily unlocked from outside. > > The original posting that started this thread involved a scenario > where a mutex could not be used for mutual exclusion, so a binary > semaphore was substituted instead. A side effect of this is that the > system cannot help avoid priority inversion problems, so that will > have to be addressed at the application level. For mutual exclusion > usage, you need to worry about what happens if the application > incorrectly executes a sequence lock/unlock/unlock/lock. IMO this > should result in an assertion failure inside the second unlock, to > facilitate tracking down the problem. I think that original post has a scenario for which there is no primitive in eCos that exactly matches requirements and there will never be one I guess as the problem that should be solved is rather complex and hopefully rare. Somebody (you?) described it as "mutual exclusion between thread groups". For me it belongs to the same class as read-write locks but apparently is even more complicated. One of solutions, IMHO, is to implement special object on top of primitives that eCos provides and use it in the application. Then it will be this object that will take care of preserving semantics of eCos primitives it uses. And if it is possible to build it on top of current binary semaphore, it is also possible to build it on top of current counting semaphore, I believe. I'm still not convinced that tuning eCos primitive for such questionable usage is a good idea especially as it prohibits another possible application. > > Sergei described an alternative usage of binary semaphores as a > synchronization primitive, for communication between threads: > basically a way of informing other threads that some event has > happened at least once. For this usage multiple posts to a binary > semaphore should be equivalent to a single post, i.e. there is no > difference in behaviour between wait/post/wait and > wait/post/post/wait. For this usage, the assertion would be incorrect. > > Now, I am not entirely convinced that this use of binary semaphores is > a good idea. Specifically, consider the sequences of events > wait/post/post/wait and wait/post/wait/post, where the waits and the > posts happen in different threads and are not otherwise synchronized. > Depending on very subtle timing differences, e.g. when the thread > doing the posts gets timesliced, both sequences are equally likely to > happen but the resulting behaviour would be very different. I am > somewhat uncomfortable with a synchronization primitive that can lead > to such non-deterministic behaviour. The intended usage assumes that the two sequences you've mentioned don't actually make visible behavior of the program different, otherwise there is a race condition and thus the program is just incorrect. If a program is broken, it's just broken no matter what primitive is used. In the simplest case the suggested use for (otherwise obsolete?) binary semaphore is a producer-consumer model where consumer should process the recent produced data as soon as possible and it's not required to process every peace of produced data. Here single producer thread makes posts and single consumer thread makes waits on binary semaphore. It also seems to be valid to have multiple consumer threads that otherwise do the same job. This could be useful on multiprocessor systems to increase performance. > > The current binary semaphore implementation does not have the > assertion, so it is not the best solution for mutual exclusion. That > argues for a new class, e.g. Cyg_UnownedMutex, to serve that purpose. > The Cyg_Binary_Semaphore class could then be left as is, i.e. behaving > as per Sergei's event signalling usage. That could still confuse > people who are used to thinking about binary semaphores as a legal > mutual exclusion primitive, as per old reference titles. To avoid that > we could also rename Cyg_Binary_Semaphore to something else, breaking > the historical association. > > I am not sure anybody would be happy with this solution. Now about names. For me Cyg_UnownedMutex sounds strange. Maybe I don't understand something very basic, but for me "Unowned" and "Mutex" are contradicting terms. Mutex should have owning semantics, I believe. Either it is only single thread that can own mutex or "group of threads", but concept of owning is what differs mutex from semaphore, as you correctly said at the beginning of the message. To add even more to the discussion, binary semaphore could be considered to be just a counting semaphore with upper bound of count equal to 1. Current counting semaphore is then counting semaphore with upper bound set to arbitrary rather large number, e.g., INT_MAX. Then back to initial question. What is semantics when counting semaphore is at upper bound and 'post' is invoked? The discussion indicates that both semantics could be useful. Unfortunately strict semantics that disallows such operation makes it impossible to use the primitive for the purpose above. Less restrictive semantics does allow both uses. It just doesn't help to catch some programming mistakes. Having that, I think it's OK to have only a no-op semantics. I have nothing against having both semantics, I just doesn't think it is worth efforts. Sergei. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-30 2:22 ` Sergei Organov @ 2001-03-30 6:54 ` Grant Edwards 2001-03-30 7:42 ` Sergei Organov 0 siblings, 1 reply; 23+ messages in thread From: Grant Edwards @ 2001-03-30 6:54 UTC (permalink / raw) To: Sergei Organov; +Cc: bartv, ecos-discuss On Fri, Mar 30, 2001 at 02:22:43PM +0400, Sergei Organov wrote: > Exactly. I started to write my own explanation of differences, > but you already explained it perfectly. The only thing that I'd > like to make more explicit is that having owner concept not > only makes provision for implementing of priority inheritance, > but also is a good thing by itself as unlocking mutex by > non-owner is explicitly prohibited. It's like bathroom door > lock, -- once you entered the bathroom and locked the door, > nobody else can enter until you unlock it, -- that's what > mutual exclusion is about. In my situation, two people enter the bathroom. One is responsible for locking the door, the other is responsible for unlocking the door. The other pair of people isn't allowed to enter until the first pair is done. I won't speculate on why two people need to be in a locked bathroon. ;) This is apparently "wrong" in the opinion of many, but the application would be made far more complex and diffucult to maintain if I had to do the same amount of work with half the threads. I'd bascially have to have "superloop" threads polling for all outside inputs rathr than having one thread blocking on rx data from each source. I apologize if my system requirements don't fit the expectations of kernel theorists, but that's life. > Using binary semaphore for mutual exclusion resembles using of > bathroom lock that is easily unlocked from outside. A mutex is equally as easy to bypass -- you just don't call lock() before accessing the shared resource. There's no way to enforce the semantics that you call lock() on a mutex before accessing the resource just as there's no way to enforce the semantics that only one of the "owners" of a semaphore used for mutual exclusion perform the post(). Incorrect programs do not work right regardless of the semantics of the primitives. > I think that original post has a scenario for which there is no > primitive in eCos that exactly matches requirements No, eCos's binary semaphore has the _exact_ semantics I needed (including what happens on multiple post() calls). Since it's not available in the C API, I used a counting semaphore -- the semantics aren't exactly what I desired, but they're close enough to be workable. > and there will never be one There _is_ one. > I guess as the problem that should be solved is rather complex > and hopefully rare. Somebody (you?) described it as "mutual > exclusion between thread groups". > > For me it belongs to the same class as read-write locks What's a read-write lock? > but apparently is even more complicated. One of solutions, > IMHO, is to implement special object on top of primitives that > eCos provides and use it in the application. I suppose I could impliment a binary semaphore object using a counting semaphore. Seems silly. > Then it will be this object that will take care of preserving > semantics of eCos primitives it uses. And if it is possible to > build it on top of current binary semaphore, The semantics I want _is_ the current binary semaphore! The semantic difference between the binary and counting semaphore only differ for cases that "can't" happen in my program, so I'm just using the counting semaphore at the moment. > it is also possible to build it on top of current counting > semaphore, I believe. I'm still not convinced that tuning eCos > primitive for such questionable usage is a good idea especially > as it prohibits another possible application. I didn't ask for anything to be tuned. I asked (out of curiosity) why an existing primitive whose semantics matched my needs exactly wasn't made visible to the user. > > Depending on very subtle timing differences, e.g. when the > > thread doing the posts gets timesliced, both sequences are > > equally likely to happen but the resulting behaviour would be > > very different. I am somewhat uncomfortable with a > > synchronization primitive that can lead to such > > non-deterministic behaviour. > > The intended usage assumes that the two sequences you've > mentioned don't actually make visible behavior of the program > different, otherwise there is a race condition and thus the > program is just incorrect. If a program is broken, it's just > broken no matter what primitive is used. Exactly. > In the simplest case the suggested use for (otherwise > obsolete?) binary semaphore I don't understand why binary semaphores have been declared "obsolete". I have an application where I need a binary semaphore (call it a "un-owned mutex" if you want -- it's still nothing more than a binary semaphore). Do I tell management that we can't ship this product because one of the parts I need has gone obsolete? The hardware guys are always using _that_ excuse. ;) > I have nothing against having both semantics, I just doesn't > think it is worth efforts. What I asked about was using the existing binary semaphore. The amount of effort required to add the existing binary semaphore to the C api would be trivial. It wasn't done for philosophical reasons. This whole thread is basically: Why can't I use X? I don't like X. I need to do what X does. You don't want to use X. Yes I do. Using X is invalid. My product requires me to do what X does. Y is newer and cooler than X. Y won't work in my product, X will. X is obsolete, it's been replaced by Y. Y won't work in my product, X will. Yes, but in a different situation Y works better than X. Y won't work in my product. X will. You shouldn't be doing what X does. My product needs to do what X does. Y is better than X. Y won't work in my product, X will. X is obsolete. Use Y. .... -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? 2001-03-30 6:54 ` Grant Edwards @ 2001-03-30 7:42 ` Sergei Organov 0 siblings, 0 replies; 23+ messages in thread From: Sergei Organov @ 2001-03-30 7:42 UTC (permalink / raw) To: Grant Edwards; +Cc: bartv, ecos-discuss Grant, For me it seems that I didn't express my intentions clearly enough. I don't argue against your usage of binary semaphore as this usage is not for mutual exclusion in its classic form (for which we have mutexes now). Also, your usage of anything doesn't affect me, so why bother. I'm arguing against adding assertion to the current binary semaphore and against removing it entirely. That's my point. Having that it seems that both you and I are trying to achieve the same goal and thus we don't have to dispute. More below... Grant Edwards <grante@visi.com> writes: > On Fri, Mar 30, 2001 at 02:22:43PM +0400, Sergei Organov wrote: > > > Exactly. I started to write my own explanation of differences, > > but you already explained it perfectly. The only thing that I'd > > like to make more explicit is that having owner concept not > > only makes provision for implementing of priority inheritance, > > but also is a good thing by itself as unlocking mutex by > > non-owner is explicitly prohibited. It's like bathroom door > > lock, -- once you entered the bathroom and locked the door, > > nobody else can enter until you unlock it, -- that's what > > mutual exclusion is about. > > In my situation, two people enter the bathroom. One is > responsible for locking the door, the other is responsible for > unlocking the door. The other pair of people isn't allowed to > enter until the first pair is done. > > I won't speculate on why two people need to be in a locked > bathroon. ;) > > This is apparently "wrong" in the opinion of many, but the > application would be made far more complex and diffucult to > maintain if I had to do the same amount of work with half the > threads. I'd bascially have to have "superloop" threads > polling for all outside inputs rathr than having one thread > blocking on rx data from each source. I apologize if my system > requirements don't fit the expectations of kernel theorists, > but that's life. > > > Using binary semaphore for mutual exclusion resembles using of > > bathroom lock that is easily unlocked from outside. > > A mutex is equally as easy to bypass -- you just don't call > lock() before accessing the shared resource. There's no way to > enforce the semantics that you call lock() on a mutex before > accessing the resource just as there's no way to enforce the > semantics that only one of the "owners" of a semaphore used for > mutual exclusion perform the post(). Incorrect programs do not > work right regardless of the semantics of the primitives. Bypassing mutex (either don't call it or attempt to unlock) is more like breaking (physically destroying) the lock. It has nothing to do with its semantics. Semantics of binary semaphore explicitly allows to unlock it by anybody. > > > I think that original post has a scenario for which there is no > > primitive in eCos that exactly matches requirements > > No, eCos's binary semaphore has the _exact_ semantics I needed > (including what happens on multiple post() calls). I meant your high-level semantics (direct support for two persons in bathroom one of which locks the door), not low-level semantics of binary semaphore. > Since it's > not available in the C API, I used a counting semaphore -- the > semantics aren't exactly what I desired, but they're close > enough to be workable. What I don't understand in your explanation though is why binary semaphore is better for your problem than counting semaphore? It seems that it should make no difference for you. [...] > What's a read-write lock? Read-write lock grants multiple threads simultaneous read-only access to a resource. Thread that wishes to write to the resource should get exclusive access though. Thus this object has at least 'lock_for_read', 'lock_for_write', and 'unlock' methods. Multiple readers, single writer. > > > but apparently is even more complicated. One of solutions, > > IMHO, is to implement special object on top of primitives that > > eCos provides and use it in the application. > > I suppose I could impliment a binary semaphore object using a > counting semaphore. Seems silly. Once again it's not clear why binary semaphore doesn't fit. > > > Then it will be this object that will take care of preserving > > semantics of eCos primitives it uses. And if it is possible to > > build it on top of current binary semaphore, > > The semantics I want _is_ the current binary semaphore! The > semantic difference between the binary and counting semaphore > only differ for cases that "can't" happen in my program, so I'm > just using the counting semaphore at the moment. Great. What's a problem then? Does it mean that you actually don't need binary semaphore? > > > it is also possible to build it on top of current counting > > semaphore, I believe. I'm still not convinced that tuning eCos > > primitive for such questionable usage is a good idea especially > > as it prohibits another possible application. > > I didn't ask for anything to be tuned. I asked (out of > curiosity) why an existing primitive whose semantics matched my > needs exactly wasn't made visible to the user. I know you didn't. Other(s) did, and I've tried to prevent it. > > > > Depending on very subtle timing differences, e.g. when the > > > thread doing the posts gets timesliced, both sequences are > > > equally likely to happen but the resulting behaviour would be > > > very different. I am somewhat uncomfortable with a > > > synchronization primitive that can lead to such > > > non-deterministic behaviour. > > > > The intended usage assumes that the two sequences you've > > mentioned don't actually make visible behavior of the program > > different, otherwise there is a race condition and thus the > > program is just incorrect. If a program is broken, it's just > > broken no matter what primitive is used. > > Exactly. > > > In the simplest case the suggested use for (otherwise > > obsolete?) binary semaphore > > I don't understand why binary semaphores have been declared > "obsolete". I have an application where I need a binary > semaphore (call it a "un-owned mutex" if you want -- it's still > nothing more than a binary semaphore). Do I tell management > that we can't ship this product because one of the parts I need > has gone obsolete? The hardware guys are always using _that_ > excuse. ;) > > > I have nothing against having both semantics, I just doesn't > > think it is worth efforts. > > What I asked about was using the existing binary semaphore. > The amount of effort required to add the existing binary > semaphore to the C api would be trivial. It wasn't done for > philosophical reasons. And I didn't ask for anything that would made your life harder, I believe. In fact I've asked for the same thing as you, but by means of giving another example of use of binary semaphore. So I'm on your side, not on the other. [...] Sergei. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ECOS] No binary semaphore in C API? @ 2001-03-30 5:39 Rosimildo daSilva 0 siblings, 0 replies; 23+ messages in thread From: Rosimildo daSilva @ 2001-03-30 5:39 UTC (permalink / raw) To: ecos-discuss >From: Sergei Organov <osv@javad.ru> >To: bartv@redhat.com >CC: ecos-discuss@sourceware.cygnus.com >Subject: Re: [ECOS] No binary semaphore in C API? >Date: 30 Mar 2001 14:22:43 +0400 > >I think that original post has a scenario for which there is no primitive >in >eCos that exactly matches requirements and there will never be one I guess >as >the problem that should be solved is rather complex and hopefully >rare. Somebody (you?) described it as "mutual exclusion between thread >groups". For me it belongs to the same class as read-write locks but >apparently is even more complicated. One of solutions, IMHO, is to >implement >special object on top of primitives that eCos provides and use it in the >application. Then it will be this object that will take care of preserving >semantics of eCos primitives it uses. And if it is possible to build it on >top >of current binary semaphore, it is also possible to build it on top of >current >counting semaphore, I believe. > >I'm still not convinced that tuning eCos primitive for such questionable >usage >is a good idea especially as it prohibits another possible application. > I believe that the primitive(s) that Sergei was talking about is more in line with the semantic of the WIN32/OS/2 "Event" primitives. Something that has a semantic of a switch ( on/off ). This semaphore, called from now "EventX", has two states, + Reseted, Posted. Once reseted, any thread "waiting" on that semaphore will block. Once, the semaphore is "posted", all threads are unblocked, and it remains on that state until it is explicited put back on the "Reseted" state. Interface: class EventX { public: void post(); bool wait( some timeout here ); void reset(); }; As he mentioned on the first message, this type of primitive is very handy, because you do not need a "thread id" of the receiving thread to be used. I have used the "Binary" semaphores to archieve this semantic in some cases, but they never matches 100%. Rosimildo. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2001-03-30 7:42 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-03-16 12:01 [ECOS] No binary semaphore in C API? Grant Edwards 2001-03-19 13:42 ` Jonathan Larmour 2001-03-26 3:53 ` Nick Garnett 2001-03-26 7:12 ` Fabrice Gautier 2001-03-26 11:37 ` Grant Edwards 2001-03-27 2:00 ` Nick Garnett 2001-03-27 5:32 ` Grant Edwards 2001-03-28 5:29 ` Bart Veer 2001-03-28 6:45 ` Sergei Organov 2001-03-28 7:38 ` Grant Edwards 2001-03-28 7:39 ` Bart Veer 2001-03-28 10:01 ` Sergei Organov 2001-03-28 11:05 ` Grant Edwards 2001-03-29 11:51 ` Sergei Organov 2001-03-29 11:49 ` Grant Edwards 2001-03-28 10:01 ` Jonathan Larmour 2001-03-29 11:55 ` Chris Gray 2001-03-29 19:33 ` Bart Veer 2001-03-29 20:50 ` Grant Edwards 2001-03-30 2:22 ` Sergei Organov 2001-03-30 6:54 ` Grant Edwards 2001-03-30 7:42 ` Sergei Organov 2001-03-30 5:39 Rosimildo daSilva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).