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
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
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 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
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
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.
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
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
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
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
20 matches
Mail list logo
