Re: [boost] Boost.Threads, N2178, N2184, et al

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-03-22 05:46:03

"Peter Dimov" <pdimov_at_[hidden]> writes:

> Anthony Williams wrote:
>
>> For a non-pthreads platform, it might make sense to implement
>> pthreads in terms of the C++ interface, which is implementes in terms
>> of the native API, rather than implement the C++ interface in terms
>> of pthreads, which is then implemented in terms of the native API.
>
> Yes, this is possible, and there are no technical reasons to avoid this 
> implementation approach. There are, how should I put that, ideological 
> reasons to not target non-pthread platforms directly, though. At some point 
> we need to draw a line and say: this is the thread abstraction we're coding 
> against, and could vendors please get along with the program?

Well, if we *do* include pthreads AND a C++ API as part of the C++ Standard,
then that's quite a good hint. It doesn't mean that you have to implement one
in terms of the other, though.

> This stance is obviously unsustainable if there are strong technical reasons 
> against it. But I think that there aren't.

Is performance not a legitimate reason? What about avoiding unnecessary
complications?

>> Lets take call_once, for example. PThreads only allows a real
>> function with no parameters returning void as the once function. This
>> is relatively easy to implement on top of a C++-style call_once that
>> allows arbitrary function objects with parameters, whereas it is much
>> harder to do the reverse.
>
> There is a note in N2178 that shows how to implement call_once on top of 
> pthread_once2_np. ;-) 

I know that it's possible, just "much harder": pretty much anything is more
complicated than

typedef once_flag pthread_once_t;
int pthread_once(pthread_once_t* once_control,void(*init_routine)())
{
    std::call_once(*once_control,init_routine);
    return 0;
}

Since on Windows the code for call_once is pretty much the same whether or not
init_routine takes arguments, it seems pointless to go round the houses
setting thread-specific data just for the benefit of writing call_once in
terms of pthread_once rather than vice versa.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL