🔒 Locked

Multicore woes

Started by mightypigeon Nov 14, 2007 at 8:24 PM 8 replies 1.3k views

Original Post

Nov 14, 2007 at 8:24 PM

Hi guys, I have been working on a fairly substantial overhaul of an app for work. I am now using a number of threads, and it runs adequately - on single core machines. We have tested on two dual core machines (an AMD and an Intel) and both demonstrate wierd behaviour, sometimes crashing... just generally uncool stuff. However if you set the process affinity in task manager whilst the app is loading (if you're quick enough ;) ) then it runs fine. I was wondering if there is a way to disable CPU affinity for a process and force it to use only one CPU/core. I know how to set the affinity for a particular thread, however I am using a couple of external libraries that have their own threading routines that I can't really touch. I'd be happy if I had to write another app that would launch the actual EXE and force the process to one CPU. Are there any Win32 API functions that exist for this? Thanks in advance, Luke.

Zao

Nov 14, 2007 at 8:36 PM

Sounds to me like you are having some concurrency issues.
Make sure that everything is adequately protected by synchronization primitives like mutexes, and that you do not have any deadlocks.
Locking the affinity smells like a hack to me.

As for setting the affinity, there exists functions for that, and notable is that affinity is inherited when starting processes.

swiftcoder

Nov 14, 2007 at 8:48 PM

if your app is crashing on multi-core machines, and the only threads are managed by libraries you are using, then i would hazard a guess that you are using one of these libraries incorrectly. Take a close look at the documentation, and see if you are violating a directive somewhere.

Telastyn

Nov 14, 2007 at 10:06 PM

Probably, but what's the point of overhauling the app to use threading only to disable it because it was buggy as sin? Fix the problem, not the symptoms.

mightypigeon

Nov 15, 2007 at 12:53 AM

Obviously, I do want to have it running on multicore and singlecore machines properly but I don't have the time or resources at the moment to sort it out. If I had access to a multicore machine to develop on I'd be able to but I won't have one for quite some time.

I am only hazarding a guess that external libraries are causing woes but I can't be sure as, like I said, I don't have the resources to debug on.

Telastyn: I'm not disabling threads. I want to disable thread affinity.

Evil Steve

Nov 15, 2007 at 3:54 AM

SetProcessAfinityMask(GetCurrentProcess(), 0x01);
or SetThreadAfinityMask(GetCurrentThread(), 0x01);

will do the trick. However, this doesn't by any means guarantee it'll work correctly. There's something wrong in the code that might cause this to "just work", or it might break in the same way on other OSs, who knows.

Telastyn

Nov 15, 2007 at 7:28 AM

Quote:

Telastyn: I'm not disabling threads. I want to disable thread affinity.

Which, in practical terms means you're losing the majority of performance benefits from using them. Unless there's some sort of organizational benefit that outweighs the fact that the code is broken?

e c h o

Nov 15, 2007 at 7:49 AM

Seeing as it runs OK on a single core CPU makes me think it's a race condition. On a single core CPU the threads never are actually run in parallel, so the you will generally not get problems. However when there are multiple cores, the threads are truly run in parallel and unlocked/unsafe data reads/writes become an issue.

I'd suggest tighter control on what data is shared between threads and putting locks in place (critical section/mutex etc).

Forcing the application to one physical core sounds like a nasty hack. Do it again, do it right.

Antheus

Nov 15, 2007 at 8:08 AM

Quote:
Original post by mightypigeon
Obviously, I do want to have it running on multicore and singlecore machines properly but I don't have the time or resources at the moment to sort it out. If I had access to a multicore machine to develop on I'd be able to but I won't have one for quite some time.

You'll be deploying a broken application. Even if you think it works, it really doesn't. Just your machine is just fast/slow enough to not exhibit the concurrency issues. Depending on where you work, this may or many not be acceptable quality.

I can only hope your work does not involve a Therac-25 machine, or that your software doesn't control large power grids, both of which involved a race condition.

If you disable CPU affinity - you're mopping the problem under the floor.

mightypigeon

Nov 15, 2007 at 7:16 PM

Alright. Thanks guys.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.