Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
- Subject: Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
- From: Philippe Wicker <email@hidden>
- Date: Fri, 8 Aug 2003 18:57:40 +0200
On Friday, August 8, 2003, at 10:46 AM, Urs Heckmann wrote:
Am Freitag, 08.08.03, um 03:41 Uhr (Europe/Berlin) schrieb Bill
Stewart:
In your Render call, you get the thread ID (pthread_self), of the
thread that you are being asked to render on.
In your API calls for starting and stopping notes you compare that
thread ID with the thread ID you are being called on to start/stop a
note, If it is the render thread, then you go through and do the work
immediately, if not, you queue a start/stop note
Thanks, this is fairly simple 8-)
But now I have another one:
- Imagine an intelligent host on a multiprocessor machine.
- It sees a bunch of Notes comming. Hence it takes its measures.
- It transfers the rendering from cpu A to cpu B, probably changing
thread ID of rendering, right?
I don't think the host can do that. The IO thread is not directly
created by the host code, but by some code in the CoreAudio framework
(HAL? when the device is started?) which is of course called by the
host. Beside, I never could find an API giving the possibility to the
user to force a thread to be executed on a given processor. If someone
knows about such an API I am really interested in knowing it. Mac OS X
is based on a SMP kernel. The 'S' stands for Symmetric. It means that
the processors are equivalent as far as cpu ressource allocation is
concerned. If a thread A is yielded the cpu, it will run on, say,
processor 1 until it is preempted by the kernel. When the kernel wakes
up again this thread A, it will look for the availability of a
processor, and may choose to "activate" thread A on processor 2 if this
is currently the best choice.
- The Queue is called, still on cpu A, finds the right thread ID and
assumes safe immediate processing
- Some cycles thereafter rendering starts on cpu B, it alters the
thread ID, but too late...
- process interrupts queue, both work on same data -> leak, crash,
hanging note, whatever
Couldn't that happen?
If my brilliant demonstration above is not another of my numerous
idiocies, I think it cannot happen :-))
Hence, shouldn't one always use the thread safe queue and never assume
safe to process immediately?
This will always work.
Cheers,
;) Urs
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.