DosSetThreadAffinity - process or thread only?

[Dariusz Piatkowski]

Trying to learn a bit about SMP capabilities on our platform and I would like to understand the functionality of the DosSetThreadAffinity API.

The Toolkit 'Programming Guide and Reference Addendum' states "...DosSetThreadAffinity allows the calling thread to change the processor affinity mask for the current thread...", so this very much feels like THREAD only control for the current thread I am in, as in: executing right now.

In the meantime, I am curious if this can be applied to a process, and by default all of it's threads?

Further on, could I develop a system driver which would enforce the execution of specific programs (i.e. processes) on a specific CPU/core of a SMP system?

The example code shown in the addendum is:

Code: [Select]

#define INCL_DOS
#define INCL_32
#define INCL_DOSERRORS
#define INCL_NOPMAPI
#include <os2.h>
#include <stdio.h>

int main(void)
{
APIRET rc;
MPAFFINITY affinity;

rc = DosSetThreadAffinity(affinity);
printf("Set thread's affinity rc = %08.8xh\n", rc);
printf("Set thread's affinity affinity[0] = %08.8xh, affinity[1] = %08.8xh\n",
        affinity.mask[0], affinity.mask[1]);
return rc;
}

Given what is shown above, and the fact that no 'target THREAD' parameter is provided, I conclude that indeed this API will only control the current thread.

Any ideas where else I could dig up some info on this and the DosQueryThreadAffinity APIs?

Thanks, as always!

[Andi B.]

No clue what you're trying to archive but OS/2 runs threads on different cores. Not only whole processes like some other OSes do (did). If you monitor your widget you also may see that OS/2 seem to switch threads from core to core regularly.

Further on, could I develop a system driver which would enforce the execution of specific programs (i.e. processes) on a specific CPU/core of a SMP system?

Again, not processes but threads run on different cores. Why do you want to force to OS to run one thread on a specific core? Do you wanna overheat a single core?

Only exception AFAIK is interrupts. They always run on core 0 and no other core. Think this is similar with a lot of (all?) other OSes.

[Dariusz Piatkowski]

Hi Andi,

...OS/2 runs threads on different cores. Not only whole processes like some other OSes do (did). If you monitor your widget you also may see that OS/2 seem to switch threads from core to core regularly...

Yes, agreed, this I completely understand.

Further on, could I develop a system driver which would enforce the execution of specific programs (i.e. processes) on a specific CPU/core of a SMP system?

Again, not processes but threads run on different cores. Why do you want to force to OS to run one thread on a specific core? Do you wanna overheat a single core?...

So for me this is a combination of two things:

1) OS/2
- I have a persistent problem with a few specific applications where starting them will freeze my machine, however if I shut down all but a single core the app starts up just fine, re-enabling all other cores following this will allow the OS/2 scheduler to dispatch the threads across all other cores, exactly as you highlighted above

- I have been told that this may be a SNAP driver bug, perhaps, I simply do not know, but I am trying to understand why this is taking place and why marking the EXE as MPUNSAFE doesn't seem to address the issue

- subsequently if I were to build a wrapper that attaches it's main thread to a specific core I am curious if starting another process by that thread would therefore apply and force the 'offending' app to retain that core affinity setting? If this were proven out, I could have a driver (as per my original thread) that would cause such specific apps to be bound to a single core during startup, thus perhaps addressing the issue I'm seeing

2) ACADEMIC
- way back in '94-'95 I did my undergrad thesis on the topic of backprop neural networks, training anything with a most primitive net architecture took a VEEERRYYYYY long time (LOL)

- ever since the SMP realm became reality for us mainstream users I often thought (just for a little fun) of rewriting my old code to take advantage of this

- like I said, this is pure academic curiosity as I still have the old training dataset and results (part of my thesis paper) and it would be a blast to see the orders of magnitude differences

- architecturally I would want to run the main net driver on a single core and dynamically balance the network layer execution without spinning up too many threads and ending up competing for the very same resource, that being CPU cycles given how compute intensive net training is

...yeah, that's all!