Re: [boost] [thread] semaphore

Subject: Re: [boost] [thread] semaphore
From: Francisco José Tapia (fjtapia_at_[hidden])
Date: 2013-09-18 11:50:32

I think the semaphores are a good idea. When you work with low latency
concurrent data structures, the mutex and condition variables are very
slow. Even the spinlocks done with atomic variables are slow.
 In my library [countertree + suballocator] the suballocator spends 0.74
seconds in allocate 50000000 elements, the same code with a spinlock spends
3.5 seconds.

I am agree with the critics to the standard, but my main critics to the
standard is that many times they forget the "common people" language. I see
when explain to my students. I must translate from the "expert" language to
the "common people" language, and then they understand the use and
functionality of the things. If they have problems for to understand, they
will have problems when use it. I think this is a main part of the problems
using the semaphores.

I know it is not easy ( I know by experience), but spend time in this ,
save time of a lot of people.

2013/9/18 Tim Blechmann <tim_at_[hidden]>

> >> many use cases is not necessary. and locks are not free, as they involve
> >> memory barriers and atomic operations. and how many platforms implement
> >> PI mutexes?
> >
> > Don't semaphores involve memory barriers and/or atomics too?  POSIX
> > semaphores do.
> >
> > (N.B. I'm not disputing that semaphores have less overhead than CVs.)
>
> they do, but much less: according to some micro-benchmarks with much
> contention, dispatch semaphores on osx are about 80 times faster than
> CVs, while posix semaphores on linux are about 30 times faster.
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>