Jon Biggar said:
> 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.
>
> It would be nice
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
Bri
"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, h
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
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 error-pron
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
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 wan
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. Wheth
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, memor
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
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:
>
> 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
>
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
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 Thr
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 al
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
> (p
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.
>
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 a
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 o
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 (the
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 mute
"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
"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 fo
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 h
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 it.
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:
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.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
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 Micro
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 conditions/
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:
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:
>
> 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 be
"William E. Kempf" wrote:
[...]
> As Alexander points out, some of the justification is similar to the
> justification of events.
Yup. http://groups.google.com/groups?selm=3BE7ABD3.6303D8E1%40web.de
Don't miss this: (see Pg. 5 -- they even have the "[Dijkstra 68]" quote)
ftp://gatekeeper.rese
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:
http://www.amazon.com/exec/obidos/ASIN
Nicolas Fleury said:
> William E. Kempf wrote:
>> Stefan Seefeld said:
>>>As boost doesn't, there must clearly be other reasons for them not to
>>> do that.
>>
>> There is, but the explanations are long and quite complex. That's why
>> the FAQ points you at a seminal paper on the subject, rather
William E. Kempf wrote:
Stefan Seefeld said:
As boost doesn't, there must clearly be other reasons for them not to do
that.
There is, but the explanations are long and quite complex. That's why the
FAQ points you at a seminal paper on the subject, rather than attempting
Correct me if I'm wrong, bu
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 tal
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
Stefan Seefeld wrote:
>
> 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).
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
Alexander Terekhov wrote:
Nicolas Fleury wrote:
Thx for the link, but I don't get it. How is Microsoft implementation
of semaphore is showing that all implementations of semaphore should be
avoided?
It is showing that semas (e.g. bin-semas aka "auto-reset events")
are really error-prone. Their
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.
> >
>
43 matches
Mail list logo
