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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk