• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ThreadSafe Note Scheduling Code (Was Re: Threading)


  • Subject: Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
  • From: Robert Grant <email@hidden>
  • Date: Fri, 8 Aug 2003 11:33:40 -0400

Maybe I'm missing something - but can somebody point out where the thread safety comes in? What about the possibility that the AU is fed MIDI data from multiple threads for example a MIDI Clock tick from one MIDI source and MIDI notes from another?

And I agree with Urs that this queue should be always used which is why I suggested a queue be part of the framework rather than something to be added by each Music AU implementor.

Thanks,

Robert.


On Friday, August 8, 2003, at 04: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?

- 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?

Hence, shouldn't one always use the thread safe queue and never assume safe to process immediately?

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.
_______________________________________________
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.

  • Follow-Ups:
    • Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
      • From: Chris Rogers <email@hidden>
References: 
 >Re: ThreadSafe Note Scheduling Code (Was Re: Threading) (From: Urs Heckmann <email@hidden>)

  • Prev by Date: Open source mixer AU proposal
  • Next by Date: Re: SetParameter at note scope?
  • Previous by thread: Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
  • Next by thread: Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
  • Index(es):
    • Date
    • Thread