On 11/15/07, Phil Endecott <spam_from_boost_dev@chezphil.org> 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