implementation of std::thread::hardware_concurrency()

[Iain Sandoe]

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" ..

cheers
Iain