Jon Biggar wrote:
[...]
There is actually one case that needs a semaphore that has no reasonable
alternative in pthreads. The only pthread synchronization operation
that is asynch-reentrant safe (i.e. can be called from a signal handler)
is signaling a pthread semaphore.
There's no such
Beman Dawes wrote:
I've expanded the FAQ entry to read:
Why has class semaphore disappeared?
Semaphore was removed as too error prone. The same effect can be
achieved with greater safety by the combination of a mutex and a
condition variable. Dijkstra (the semaphore's inventor), Hoare, and
Victor A. Wagner, Jr. wrote:
well, unless (likely given this biz) the words have changed meaning again,
naked semaphore was described by Dijkstra way back when (1964??)
http://www.cs.utexas.edu/users/EWD/index01xx.html
But just a few years later (in 1971) Sir Tony Hoare (ironically, his
William E. Kempf wrote:
I haven't seen your code to say for sure, but from the limited description
I believe there's a very high probability that this is the case.
Hm...
I'm ready to accept the argument that having two separate
synchronization primitives to do logically one task can be
well, unless (likely given this biz) the words have changed meaning again,
naked semaphore was described by Dijkstra way back when (1964??)
a mutex was a variant of a semaphore which restricted signalling (V()) to
the task/process/thread/whatever that had successfully waited (P()) on it.
often a
Hi,
Alexander Terekhov wrote:
Show me some code. I mean something that shows why do you need counting
semas.
This wording is too strong. Going this way, we can *always* say that
feature X is not deadly needed and can be replaced by two or more
(probably lower-level) features Y.
We could write
Stefan Seefeld wrote:
Alexander Terekhov wrote:
Show me some code. I mean something that shows why do you need counting
semas.
I'm using a bounded task queue (with the producer/consumer pattern),
where the queue is implemented with std::queue, a mutex, and two semaphores.
One
Maciej Sobczak wrote:
Hi,
Alexander Terekhov wrote:
Show me some code. I mean something that shows why do you need counting
semas.
This wording is too strong. Going this way, we can *always* say that
feature X is not deadly needed and can be replaced by two or more
(probably
Alexander Terekhov wrote:
I see that you're also not fond of following the links. Okay.
that's starting to get annoying...
I did follow the links, I just don't happen to agree with what
was said there. No need to paste it again here.
This is far from elegant, because the queue data structure
Hi,
Alexander Terekhov wrote:
and, believe
me, you'll realize rather quickly that monitors based on MESA/POSIX condvars
are much, much better than anything you could do with semas
I understand your point.
I have been using Windows API *before* I got a chance to read
Programming with POSIX
Stefan Seefeld said:
Alexander Terekhov wrote:
This is far from elegant, because the queue data structure already
knows the number of messages either implicitly or with an extra
counter of its own.
well, I need to know it explicitely when I want to extract the next one,
so either the queue
Stefan Seefeld wrote:
Alexander Terekhov wrote:
I see that you're also not fond of following the links. Okay.
that's starting to get annoying...
Yeah. My wife also says that this is something I do best. ;-)
I did follow the links, I just don't happen to agree with what
was said
William E. Kempf wrote:
so what ? the 'real' queue length is kept private and doesn't matter
much. It's the signaling of the semaphore that makes the change public.
This is a race condition. It also occurs when extracting data from the
queue. Whether or not the 'real' queue length is private
Stefan Seefeld wrote:
[...]
And then there is the other semaphore I use to count the free slots,
which you didn't comment on, probably because it didn't fit into your
arguments...
No, actually, it strengthens the argument, because you now have even more
state that needs to be
Maciej Sobczak wrote:
[...]
What about providing both (condvars and semas), but with documenting
known pros and cons?
Personally, I'd have no problems with some *separate* Boost.Semas (for
things meant to be done by the current POSIX/IPC semaphores: async-
signal-safe unlock operation,
Stefan Seefeld said:
William E. Kempf wrote:
so what ? the 'real' queue length is kept private and doesn't matter
much. It's the signaling of the semaphore that makes the change
public.
This is a race condition. It also occurs when extracting data from
the queue. Whether or not the
William E. Kempf wrote:
As soon as synchronization relies on *BOTH* a mutex and a sema/event,
you've got a race condition.
hmm, I'm not sure I have the same definition for 'race condition' as
you have. Of course I could write non-safe code that presents a race
condition. Is your point that you
Stefan Seefeld said:
William E. Kempf wrote:
As soon as synchronization relies on *BOTH* a mutex and a sema/event,
you've got a race condition.
hmm, I'm not sure I have the same definition for 'race condition' as you
have. Of course I could write non-safe code that presents a race
I'm baffled that they want to penalize (time and space) those for whom a
naked semaphore works. It's blatantly clear to anyone who's had to write a
mutex that it's additional code on TOP of a semaphore.
we always implemented semaphore first, then added the mutex wrapper for
those who needed
a poor implementation is no reason to ass/u/me that the concept is poor
At Wednesday 2003-06-04 12:23, you wrote:
Nicolas Fleury wrote:
[...]
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
Would it be possible to post some code that experience has
Victor A. Wagner, Jr. wrote:
I'm baffled that they want to penalize (time and space) those for whom a
naked semaphore works. It's blatantly clear to anyone who's had to write a
mutex that it's additional code on TOP of a semaphore.
Optimization stratergies aside (they are different for
Victor A. Wagner, Jr. wrote:
I'm baffled that they want to penalize (time and space) those for whom a
naked semaphore works.
Show me please an example illustrating naked semaphore in work.
It's blatantly clear to anyone who's had to write a
mutex that it's
Hi,
Victor A. Wagner, Jr. wrote:
I've also never actually _seen_ the implementation of a semaphore with a
mutex and a condition variable, and don't readily envision it.
Well...
My university background considering synchronization was based on Modula
and some abstract course where semas and
Alexander Terekhov wrote:
Victor A. Wagner, Jr. wrote:
I'm baffled that they want to penalize (time and space) those for whom a
naked semaphore works. It's blatantly clear to anyone who's had to write a
mutex that it's additional code on TOP of a semaphore.
Optimization stratergies aside (they
Stefan Seefeld wrote:
[...]
But binary semaphore are only a (small) subclass of semaphores, and I'd
use semaphores mostly to represent value *and* lock, where the value's
domain is larger than just 1/0.
Show me some code. I mean something that shows why do you need counting
semas.
regards,
Alexander Terekhov wrote:
Show me some code. I mean something that shows why do you need counting
semas.
I'm using a bounded task queue (with the producer/consumer pattern),
where the queue is implemented with std::queue, a mutex, and two semaphores.
One semaphore counts the available tasks, the
Stefan Seefeld wrote:
hi there,
I'v been trying to find some info as to why semaphores
are considered harmful by the boost::thread authors,
without luck. Is there any concise text describing
the problem ?
Well,
http://www.boost.org/libs/thread/doc/faq.html#question10
I'v been using
Alexander Terekhov wrote:
Stefan Seefeld wrote:
hi there,
I'v been trying to find some info as to why semaphores
are considered harmful by the boost::thread authors,
without luck. Is there any concise text describing
the problem ?
Well,
http://www.boost.org/libs/thread/doc/faq.html#question10
Stefan Seefeld wrote:
[...]
I'm still not convinced.
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Alexander Terekhov wrote:
Stefan Seefeld wrote:
[...]
I'm still not convinced.
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with
Nicolas Fleury wrote:
[...]
http://google.com/groups?selm=3CED3306.DF6DB829%40web.de
(Subject: Re: many semaphores)
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft
Alexander Terekhov wrote:
Nicolas Fleury wrote:
[...]
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft Corp.
Nicolas Fleury wrote:
Alexander Terekhov wrote:
Nicolas Fleury wrote:
[...]
Would it be possible to post some code that experience has shown to be
error-prone using semaphores comparing with conditions/mutexes?
Sure... thanks to the Microsoft Corp.
Alexander Terekhov wrote:
It is showing that semas (e.g. bin-semas aka auto-reset events)
are really error-prone.
you seem to equate microsoft's implementation of semaphores with
the concept of semaphores (which is what I'd like to get feedback on).
If all that is wrong is that microsoft does a
Stefan Seefeld said:
Alexander Terekhov wrote:
It is showing that semas (e.g. bin-semas aka auto-reset events) are
really error-prone.
you seem to equate microsoft's implementation of semaphores with
the concept of semaphores (which is what I'd like to get feedback on).
No, you miss
Nicolas Fleury wrote:
[...]
It is showing that semas (e.g. bin-semas aka auto-reset events)
are really error-prone. Their implementation of counting semaphore
How?
Review the code. You'll see that it has many problems. One problem
is precisely the thing that POSIX rationale is talking
Nicolas Fleury wrote:
[...]
What is the paper you have in mind to justify the absence of semaphores?
I would like very much to understand and be convinced. It would also
be nice if the #10 of the FAQ would point to this paper.
It can be found here:
37 matches
Mail list logo
