Re: [boost] [thread] thread interruption semantics

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.

--
gpd