Set processor core affinity to a thread
persres
Is there anyway I can set up a thread to run on a specific
processor core? say on Windows XP. (any other windows OS?).
Is there a direct API which can do this? If not is there some other
indirect way to achieve this?
Thanks
Anthony Williams
You can use SetThreadAffinityMask to limit which CPUs or cores a thread
can run on.
http://msdn.microsoft.com/en-us/library/ms686247%28VS.85%29.aspx
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
persres
Oh. Great. I thought it was only for .net, not so. Ever used this?.
The documentation says, it usually wont help. In that case, I wonder
why such a call exists. Cant think of any scenario. I was basically
wondering if we could think of a non-blocking threading design using
this call. just fancy experimentation..thats all.
Thanks
j...@cix.compulink.co.uk
<7e0b36dc-e7b4-4125...@e37g2000yqn.googlegroups.com>,
per...@googlemail.com (persres) wrote:
> Is there anyway I can set up a thread to run on a specific
> processor core? say on Windows XP. (any other windows OS?).
Think carefully about why you want to do this. If the software is only
ever going to run on machines that you have control of, fine.
If it's going to be run on machines belonging to other people or
organisations, that means you won't know what combinations of cores and
sockets those machines will have. How are you going to decide which core
it should run on? When you've answered that question, consider what
happens if you run several copies of the software on the same machine:
will they all pick the same core? If so, you've achieved a worse result
than letting the operating system pick cores for you. For extra credit,
consider how you might interact with other software that picks a core to
attach itself to.
Just because Windows offers a facility, that doesn't mean you should
always use it. This is an area where it's really easy to have software
achieve a worse result than leaving the decisions to the operating
system.
--
John Dallman, j...@cix.co.uk, HTML mail is treated as probable spam.
j...@cix.compulink.co.uk
<5a27310c-7a9c-403c...@a22g2000yqc.googlegroups.com>,
per...@googlemail.com (persres) wrote:
> The documentation says, it usually wont help. In that case, I wonder
> why such a call exists. Cant think of any scenario.
One would be something that has to handle hardware interrupts that are
always generated by hardware attached to a particular processor package.
Not exactly common.
> I was basically wondering if we could think of a non-blocking threading
> design using this call.
Danger lies there. Windows does not absolutely guarantee that if you
have affinity set, you will only ever execute on that core. If the
scheduler feels it has to run you on another one, it will.
persres
> In article
> <5a27310c-7a9c-403c-ad04-2adc2118a...@a22g2000yqc.googlegroups.com>,
Chris M. Thomasson
news:BvadnfCHpfYov8PW...@giganews.com...
Humm... Can you please provide me with some official documentation that
explains how `SetThreadAffinityMask()' is not reliable?
BTW, are you sure that you are not writing about
`SetThreadIdealProcessor()'? Or, perhaps are you writing about the fact that
if processor P1 is running Thread T, and you bind the affinity of T to
processor P1, then T will continue to run on P1 _until_ it is rescheduled on
P2?
Thanks!
David Schwartz
> BTW, are you sure that you are not writing about
> `SetThreadIdealProcessor()'? Or, perhaps are you writing about the fact that
> if processor P1 is running Thread T, and you bind the affinity of T to
> processor P1, then T will continue to run on P1 _until_ it is rescheduled on
> P2?
It is my understanding that if you call SetThreadAffinityMask and
disallow the current processor, the call will not return until the
thread has been rescheduled.
DS
Chris M. Thomasson
news:ddacd63d-f5b2-471b...@c34g2000yqn.googlegroups.com...
On Jan 25, 3:41 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > BTW, are you sure that you are not writing about
> > `SetThreadIdealProcessor()'? Or, perhaps are you writing about the fact
> > that
> > if processor P1 is running Thread T, and you bind the affinity of T to
> > processor P1,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That should be P2.
> then T will continue to run on P1 _until_ it is rescheduled on
> > P2?
> It is my understanding that if you call SetThreadAffinityMask and
> disallow the current processor, the call will not return until the
> thread has been rescheduled.
Yikes! I think I misread the following paragraph:
"If the new thread affinity mask does not specify the processor that is
currently running the thread, the thread is rescheduled on one of the
allowable processors."
in the document:
http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx
However, it does not really clarify if the rescheduling occurs _before_ the
actual function returns.
Humm...
Jonathan de Boyne Pollard
Danger lies there. Windows does not absolutely guarantee that if you have affinity set, you will only ever execute on that core. If the scheduler feels it has to run you on another one, it will.
Humm... Can you please provide me with some official documentation that explains how
SetThreadAffinityMask()is not reliable?
BTW, are you sure that you are not writing about
SetThreadIdealProcessor()? Or, perhaps are you writing about the fact that if processor P1 is running Thread T, and you bind the affinity of T toprocessor P1, then T will continue to run on P1 until it is rescheduled on P2?It is my understanding that if you call
SetThreadAffinityMask()and disallow the current processor, the call will not return until the thread has been rescheduled.
Your understanding is certainly in agreement with the Microsoft documentation, referenced earlier in this discussion thread. (-:
David Schwartz
> "If the new thread affinity mask does not specify the processor that is
> currently running the thread, the thread is rescheduled on one of the
> allowable processors."
>
> in the document:
>
> http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx
>
> However, it does not really clarify if the rescheduling occurs _before_ the
> actual function returns.
>
> Humm...
True. I would consider it quite foolish to rely on this function to
make any kind of guarantees.
DS
j...@cix.compulink.co.uk
Thomasson) wrote:
> Humm... Can you please provide me with some official documentation
> that explains how `SetThreadAffinityMask()' is not reliable?
>
> BTW, are you sure that you are not writing about
> `SetThreadIdealProcessor()'? Or, perhaps are you writing about the
> fact that if processor P1 is running Thread T, and you bind the
> affinity of T to processor P1, then T will continue to run on P1
> _until_ it is rescheduled on P2?
That latter is the most obvious way you might find yourself operating
outside boundaries set by SetThreadAffinityMask().
Other possibilities include the possibility of bugs in the scheduler,
and Windows trying to keep going when the processor you set affinity to
has just died.
I'm not saying that SetThreadAffinityMask() should be considered
unreliable in general. But it's a bit of a complex thing to have the
absolute reliability required for basing a non-blocking threading design
on (which doesn't appear to be its intended purpose) in the absence of
explicit guarantees.
Chris M. Thomasson
news:rJmdnd4XC6Y_8P3W...@giganews.com...
> In article <__p7n.9374$Yt6....@newsfe23.iad>, n...@spam.invalid (Chris M.
> Thomasson) wrote:
>
>> Humm... Can you please provide me with some official documentation
>> that explains how `SetThreadAffinityMask()' is not reliable?
>>
>> BTW, are you sure that you are not writing about
>> `SetThreadIdealProcessor()'? Or, perhaps are you writing about the
>> fact that if processor P1 is running Thread T, and you bind the
>> affinity of T to processor P1, then T will continue to run on P1
>> _until_ it is rescheduled on P2?
>
> That latter is the most obvious way you might find yourself operating
> outside boundaries set by SetThreadAffinityMask().
Indeed.
> Other possibilities include the possibility of bugs in the scheduler,
> and Windows trying to keep going when the processor you set affinity to
> has just died.
Ouch! :^)
> I'm not saying that SetThreadAffinityMask() should be considered
> unreliable in general. But it's a bit of a complex thing to have the
> absolute reliability required for basing a non-blocking threading design
> on (which doesn't appear to be its intended purpose)
Agreed. FWIW, there are some user-space RCU implementations that create and
bind threads to each CPU in the system (e.g., 64 CPU's would have 64
thread's). When the RCU sub-system wants to observe a synchronization epoch
it simply broadcasts a message to all of the threads and then waits for all
of them to respond. A nasty race-condition would be cast upon the RCU
implementation if one of those threads executed on a CPU other than the one
it's explicitly bound to. Yikes!
> in the absence of explicit guarantees.
I think you would need to pause the thread, set it's affinity and resume it.
The resumed thread should run on the designated processor(s). I also think
that creating a thread in a suspended state before you call
`SetThreadAffinityMask()' on it would work as well. Also, the following
paragraph in the documentation has some fairly strong language:
"Setting an affinity mask for a process or thread can result in threads
receiving less processor time, as the system is restricted from running the
threads on certain processors. In most cases, it is better to let the system
select an available processor."
The phrase:
`as the system is restricted from running the threads on certain processors'
Does seem to "imply" that the system "honors" the affinity mask. The thing
that is interesting is what happens when a processor goes offline.
:^)