Re: overloads in ioproc : why?
Re: overloads in ioproc : why?
- Subject: Re: overloads in ioproc : why?
- From: Herbie Robinson <email@hidden>
- Date: Tue, 17 Sep 2002 02:31:54 -0400
I'm using the MP queues, but I'm wondering whether the MPNotifyQueue
call is a blocking call or not (i know it's possible to design lock
free queues, but since i haven't reserved any space for my queue,
maybe the memory allocation code that's executed from this call uses
a global std lib mutex to access the heap. I need to check this).
And if this call is blocking, does it use a "real time schedule"
wait as you say seems not to always be the case ?
I don't know OS X well enough to answer that, but the point is moot.
Something to think about:
The idea is to get the OS to schedule your thread as accurately as
possible. The best way to do that is to give the OS a fixed time to
wait until. If you wait for some other thread to notify you, then
the OS doesn't get advance notice of when to schedule you.
That would mean that all you need is a circular buffer: The producer
fills it in and sets the write index. The consumer picks up values
and updates a read index. The consumer schedules by figuring out
when the next batch of data will be available and calling nanosleep.
The amount of slop allowed in the real-time scheduling parameters
will dictate how much smaller the batch size has to be relative to
the buffer size. If the producer and consumer don't have to notify
each when the buffer becomes full or empty, then no locking (or
atomic update techniques) is needed when updating the indices.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.