Boost logo

Boost :

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-11-16 04:47:24

On 11/15/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> wrote:
> Howard Hinnant wrote:
> > On Nov 15, 2007, at 7:37 AM, Phil Endecott wrote:
> >
> >> The semantics of pthread_mutex&cond_t are more complex than are needed
> >> for std::mutex&cond_var. Slightly more efficient pthread functions
> >> could be implemented by inlining (maybe some implementations already
> >> do this). But the overhead of using a single type for all kinds of mutex
> >> (recursive, non-recursive, checking etc), with run-time look up of the
> >> kind, is unavoidable. Since the optimal uncontended mutex locking
> >> code is just two inline instructions, even adding one additional 'if
> >> kind==x' will measurably reduce performance.
> >
> > Your argument above addresses pthread_mutex_t but not pthread_cond_t.
> pthread_cond_wait takes a pthread_mutex argument, so it inherits any
> problems it has. I haven't looked at pthread_cond enough to understand
> any further issues.

But it *really* is a preformance problem? Even on the fast path you
need to perform at least an atomic/ordered operation. In comparison,
the cost of an
(easy predictable) compare is very small.


Boost list run by bdawes at, gregod at, cpdaniel at, john at