• 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: Philippe Wicker <email@hidden>
  • Date: Fri, 8 Aug 2003 22:18:36 +0200

On Friday, August 8, 2003, at 08:52 PM, Chris Rogers wrote:

Hi Robert,

Yes, the code Bill posted is only thread-safe with two threads involved,
a queuing thread and a rendering thread. The thread safety breaks down
if you want to support multiple threads other than the render thread.
However, I think the code covers the 90% usage case, and I think it would be
quite considerably more expensive to expect all MusicDevice AudioUnits to
support multiple "secondary" threads, since this would requires thread
synchronization locks which in addition to being expensive could
block the render thread which would be really bad! I think at this point,
the host would have to provide responsibility for the thread synchronization,
and luckily I think this would rarely be necessary.

I think the code is completely thread safe for one single queuing
thread and one rendering thread, although it's always nice to have
people look at it to verify our assumptions...

This kind of queue is still thread-safe when used in a (n producers / 1 consumer) configuration provided that a lock (a mutex) is added on the producer side. This mutex protects against concurrent producers accesses without any blocking side effect on the consumer side. So provided this additional mutex, the pthread_mutex_init and pthread_mutex_lock/unlock calls at the correct places, the same code could be used with n midi threads and 1 render thread. At first glance, it should be enough to enclose the code of QueueExtendedNoteOn and QueueExtendedNoteOff with a pair of pthread_mutex_lock/unlock.


Chris Rogers
Core Audio
Apple Computer


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.

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.

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

  • Prev by Date: Re: Open source mixer AU proposal
  • Next by Date: Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
  • 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