[Prev] Thread [Next] |
[Prev] Date [Next]
Re: Thread Affinity - posix vs. cocoa threads
Wed Jul 16 05:05:22 2008
So use the thread_policy_get/thread_policy_set API:
I _do_. I don't even know another possibility on MacOS (and only
If one wants a thread to already have some affinity information
when it starts executing, one has to use Cocoa (as far as I
understand), and this is well described in the documentation you
have cited. However, pthreads aren't even mentioned there —
perhaps the affinity API just doesn't work well for threads
I don't know of any other API either. In fact, as far as I can see
you can't play with the affinity of an NSThread directly; you could
at best, in the thread itself, call mach_thread_self() and then
thread_policy_set. Is there some other way I'm not aware of?
I have no experience with Cocoa, but reading the affinity API
documentation I had the impression it should be obvious how to do
that. Perhaps one should use the basic mach interface, but the API
documentation is really vague in that respect.
But with pthreads, I can only spawn a thread without affinity (I
think this is the default) and set its affinity tag when it is
already running. As it seems, setting the thread affinity will not
make Leopard migrate threads with the same affinity tag to the
same die (i.e. shared cache), at least not in reasonable time.
You can create a pthread that is initially suspended, using
pthread_create_suspended_np. Note the "_np" prefix which stands
for "non-portable", as in, not POSIX.1. You can then get its Mach
handle with pthread_mach_thread_np and fiddle with its affinity,
then use the thread_resume to kick it off.
Thanks alot. I know of nonportable pthread extensions from Linux,
but usually try to avoid them. Wasn't aware some are available on
MacOS, too, because they were mentioned nowhere in the documentation
I looked through.
Can you provide more information about the behaviour you're
observing? How are you monitoring your threads? What is
"reasonable time"? Etc.
Usually I use the Activity Monitor.app, but if applications try
exploiting shared caches, it also sufficient to measure run time.
"Reasonable time" until a desired configuration is found would be in
the order of a few seconds. For unknown reasons, MacOS likes
migrating threads frequently, so I cannot tell if the threads will
find a suitable configuration after a few minutes.
If I start two threads with the same affinity tag, I expect them to
be running on the same die "most of the time", at least with an
increased probability. Sometimes I am unsure if the affinity tags
have any influence at all.
Even after looking through documentation and code for some time,
there is still the possibilty I'm doing something wrong, or that the
problem is related to my machine (MacPro Penryn 2.8 8-core, MacOS
I have created a small demo program I've attached with this email.
It starts a number of "thread pairs" which operate on a common
volatile int, flipping it's value from 0 to 1. On the command lines,
the number of thread pairs and an affinity tag for each thread must
be given, e.g. "./pingpong 2 1 1 2 3" results in two thread pairs,
both threads of the first pair with affinity tag "1", and one thread
of the second pair has 2 and one 3.
Sorry, my last posting included the wrong file…
Here's the correct one.
Do not post admin requests to the list. They will be ignored.
Mt-smp mailing list ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:
This email sent to [EMAIL PROTECTED]