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

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-03-23 04:16:38

Peter Dimov wrote:
> Johan Nilsson wrote:
>> Peter Dimov wrote:
>>> 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.
>>
>> Wow, this caught my eye when lurking around. Are we promoting
>> Windows-bashing for its own sake here ;-)
>
> No, you misunderstood.
>
> We are promoting ISO/IEC 9945 as a standard threading abstraction.

IIUC that is "The Single UNIX Specification", I assume you mean the
"pthread.h" part of it?

> We
> are (hypothetically) providing an implementation for Windows as a
> service to the users/developers and as a proof of viability. We are
> encouraging Microsoft
> to supply its own implementation because they can do it better than
> us with access to the kernel.

Even if they did, that'd have to be implemented as an update or add-on
for current platforms. Requiring post-Vista versions of Windows for
having threads available under C++ doesn't seem right to me.

Also, what about unsupported OS's such as NT4? Microsoft will never
release any officially supported updates to such platforms.

Basically, what I'm saying is that any Win32 C/C++ thread
implementation still has to provide its own threading support as it
can't rely on pthreads being available. Or, sorry, was that what you
actually meant, that the standard C++ library would "have to" include
kernel modules for best performance under Windows?

Am I still misunderstanding? I have a nagging feeling that I do ...

>
>> I'd be surprised if there were no performance considerations at all.
>
> One would expect a C++ programmer to be more careful with that
> argument, given his constant exposure to C programmers who really
> would be surprised
> if using C++ doesn't make their code slower. ;-)

Touché. But, still - without any firm evidence I believe that "C++ ->
pthreads layer -> Win32 threads" is slower than "C++ -> Win32 threads",
which is what I based my assumption upon.

>
> That aside, if there is a legitimate design-imposed source of
> inefficiency
> in N2178, I'll be glad to know about it so that it can be fixed.

I never said it was. To be honest though, I've only glanced at the proposal,
so I'll give it another shot.

/ Johan