mt-smp

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Thread Affinity - posix vs. cocoa threads Markus Stürmer Wed Jul 16 05:05:22 2008

So use the thread_policy_get/thread_policy_set API:
<http://developer.apple.com/releasenotes/Performance/RN-AffinityAPI/ >

I _do_. I don't even know another possibility on MacOS (and only with Leopard).

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 already executing.

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.

Wade


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 10.5.4).

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.

Regards,
Markus

Sorry, my last posting included the wrong file…

Here's the correct one.

Regards,
Markus


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Mt-smp mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mt-smp/alexiscircle%40gmail.com

This email sent to [EMAIL PROTECTED]