implementation of std::thread::hardware_concurrency()

[Iain Sandoe]

On 7 Nov 2011, at 14:23, Iain Sandoe wrote:

> On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
>
>> On 7 November 2011 14:10, Iain Sandoe wrote:
>>>
>>> On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
>>>
>>>> This provides a working thread::hardware_concurrency on platforms  
>>>> that
>>>> support pthread_num_processors_np or the "hw.ncpu" sysctl, but by
>>>> testing for the features in configure rather than hardcoding OS  
>>>> macro
>>>> tests in thread.cc
>>>
>>> if the system supports run-time User-controllable core-count then  
>>> this will
>>> not account for that.
>>
>> Yep.  Do you know how to detect the right value in that case?  If not
>> the alternative is to revert to the previous behaviour of returning
>> zero.
>>
>> (My understanding was that at least some of the options would work  
>> for
>> that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF,  
>> for
>> example)
>
> Hm. I don't know about the general case - on Darwin it's certainly  
> possible to get at the information at runtime;
>
> hw.logicalcpu_max: 4
> hw.logicalcpu: 4
> hw.physicalcpu_max: 4
> hw.physicalcpu: 4
> hw.ncpu = 4
>
> and ... switching the control panel to dual CPU ..
>
> hw.logicalcpu_max: 4
> hw.logicalcpu: 2
> hw.physicalcpu_max: 4
> hw.physicalcpu: 2
> hw.ncpu = 4
>
> but, as you say, that would be the implication of "ONLN" vs "CONF" ..

however, apparently not - ...

#include <unistd.h>
#include <stdio.h>

int main (int ac, char *avv[])
{
   printf ("n-procs: %d\n", sysconf (_SC_NPROCESSORS_ONLN));
}

$ gcc-4.2 ../tests/nprocs.c -o tt

./tt
n-procs: 4

.. switched to dual cpu ...

$ sysctl hw.logicalcpu
hw.logicalcpu: 2

$ ./tt
n-procs: 4

:-(

so there's a reason to use the systlbyname (and use hw.logicalcpu or  
similar, maybe).
[unless that's just a buggy sysconf]

Iain