Re: Multiprocessor support: OpenMP problem in Core Audio thread
Re: Multiprocessor support: OpenMP problem in Core Audio thread
- Subject: Re: Multiprocessor support: OpenMP problem in Core Audio thread
- From: Jeff Moore <email@hidden>
- Date: Wed, 06 May 2009 14:29:38 -0700
There really isn't a whole lot of documentation on the topic of time
constraint threads. What little there is will be in the kernel
documentation. But basically, a time constraint thread is a thread
that runs in the highest priority band on the system. It can and will
pre-empt pretty much everything.
Another important aspect of a time constraint thread is that their
priority does not degrade until after the deadline has passed. So any
construct that relies on priority degradation to do it's job (like a
spin lock) won't function properly on a real time thread.
As you might imagine, there are a few catches for the code executing
on a time constraint thread. First, you have to tell the scheduler
what your real-time deadlines are. Second, you have to promise to
abide by them. The scheduler will punish threads that miss their
deadlines by pre-empting them as well as by severely degrading their
priority.
Give all that, code executing on a time constraint thread has to avoid
doing things that block indefinitely like allocating memory or locking
a mutex without a time-out or what have you. Note that this implies
that most of the user-land APIs are off-limits as many of those APIs
block (and if they don't say if they block or not, you should always
assume that they do).
That said, the consequences for failing to meet a real-time deadline
are definitely not crashes. So, I'd be more likely to believe that
this is some kind of code-gen problem. Plus, the exception code of the
crash is indicating a bad memory access of some flavor. Most likely
there is some data structure that the OpenMP code is trying to access
from the real time thread that isn't either corrupt or non-existent or
otherwise messed up.
On May 6, 2009, at 1:26 PM, Dan wrote:
2009/5/6, Dave Fernandes <email@hidden>:
The gcc / OpenMP version that ships with Leopard/Xcode has a known
bug that
it does not work on any thread other than the main thread. This was
apparently fixed on a later version of gcc, but I expect you would be
installing and using a later version at your own risk.
Ah, thanks for this, I wasn't aware of such a bug. However, I've now
tried it with other gcc versions (gcc-mp-4.3, gcc-mp-4.4,
gcc-apple-4.2, all from macports) and they exhibit the exact same
crash; so unless the bug is widespread, I suspect it may be the issue
described by Jeff:
2009/5/5, Jeff Moore <email@hidden>:
The thread context on which IO happens in Mac OS X is a time
constraint
thread. This is very different from a normal thread context. Among
other
things, you have to avoid allocating memory or doing any other
operation
that can block. My guess would be that OpenMP has some baseline
incompatibility when running in this context.
This sounds plausible. I wonder if there is any way to reconcile the
two.
A web search doesn't find me much about "time constraint thread" -
could you point me towards some documentation about this type of
thread? (Core-Audio-specific references would be nice if known)
Thanks
Dan
On May 5, 2009, at 5:31 PM, Dan wrote:
Hi -
I was working on adding multiprocessor support to a piece of audio
software, by using OpenMP <http://www.openmp.org>. I can compile and
run OpenMP-enabled code fine - but *not* if the parallelised code is
in the Core Audio callback. If you add something like this, for
example:
#pragma omp parallel for
for(i=0; i<4; ++i){ // the iterations could occur on different cores
printf("%i\n", i);
}
...it will work fine in many cases, but will crash the app if in the
callback. The crash always looks something like this:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000028
Thread 13 Crashed:
0 libgomp.1.dylib 0x000129cc
gomp_resolve_num_threads + 76 (libgomp.h:380)
1 <<00000000>> 0xf070db60 0 + -261039264
2 libgomp.1.dylib 0x00012b34
GOMP_parallel_start +
48 (parallel.c:107)
So my question is: is there something about the way Core Audio works
that conflicts with what OpenMP does (namely, dynamically create
threads and distribute them across processors)? Is there any way you
can think of, that might allow the two to play nicely together?
Thanks in advance for any thoughts -
Dan
--
http://www.mcld.co.uk
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden