Processor affinity

Processor affinity

Post by kej » Fri, 02 Apr 2004 23:06:43

Hi there
I am looking for a way to programmatically tie my app to only run on
one processor when being launched on a dualprocessor Mac, eg. a G5.
The problem only concerns Mac OSX, where some synchronization between
threads occationally crash the app.
This happens in LInterruptsafeList.cp and I have tried to implement a
couple of solutions found in this group. That has lowered the
frequency of crashes, but not removed them entirely.

In an old (2002) thread I found a statement that it was possible in
OSX to make one app run on one processor and another app run on the
other processor. Unfortunately there was no hint to what should be

Hoping that someone outhere can help.


Processor affinity

Post by Gregory We » Sun, 04 Apr 2004 22:52:36

In article < XXXX@XXXXX.COM >,

I'm not sure that can actually be done with OS X, but it really doesn't
matter. Restricting a process to a single CPU in an MP machine isn't
going to magically fix thread synchronization issues.

Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses. - Jeremy Nixon


Processor affinity

Post by David Dunh » Fri, 16 Apr 2004 13:48:06

In article < XXXX@XXXXX.COM >, Keld

While it's true that multiple processors can expose threading bugs more
quickly, it's probably best to track down and fix the bugs. You'd just
be hiding them.

David Dunham A Sharp XXXX@XXXXX.COM
"I say we should listen to the customers and give them what they want."
"What they want is better products for free." --Scott Adams

Processor affinity

Post by Chris Hans » Sun, 02 May 2004 10:36:48

I could be wrong, but I don't think there's any such thing as
"processor affinity" on Mac OS X.

Really, all such a thing would do anyway is mask bugs in your code.
(If your code is crashing when it runs multithreaded, it has bugs.)
Your best bet would be to go through and check how you're accessing
your shared data structures to make sure you're properly controlling
access to them.

I've found a good way to do that is to only manipulate shared
structures through accessors that implement the locking. That way
things don't get into an inconsistent state. Naming them something
inconvenient can help, as it'll "encourage" you to go through the

-- Chris

Chris Hanson < XXXX@XXXXX.COM >