Re: IOProc limitations
Re: IOProc limitations
- Subject: Re: IOProc limitations
- From: Jeff Moore <email@hidden>
- Date: Tue, 19 Jun 2001 14:30:05 -0700
on 6/19/01 1:18 PM, James McCartney <email@hidden> wrote:
>
on 6/19/01 2:34 PM, Jeff Moore at email@hidden wrote:
>
>
> you've done is boosted it's priority over a short period of time. It then
>
> has to compete with the other threads on the system, including other audio
>
> threads.
>
>
That should not be a problem because I will be sharing the CPU with other
>
tasks of the same urgency, thus the same amount of work will get done by the
>
same deadline. Order should not be important.
The problem is that if you block the IOThread to wait for some other thread
to do work on behalf of the IOThread, you are giving the scheduler the
opportunity to schedule any number of other equal priority threads before
getting back to the thread you want to run.
Data is not collected serially from all the apps doing IO with a device.
Each process will have its duty cycle out of phase with other processes
doing IO to the same device. Recall that each process can have a different
buffer size.
>
I don't see why a SysBeep would be a problem.
It's a problem because it causes a process to do something on a real time
thread that is the same priority as your thread. The competition can yield
results you don't expect, but need to account for.
>
If you are overallocated on CPU then you are over allocated and there is
>
nothing you can do. But if not, then all tasks will still complete on time.
True, but the fact that the processes are all skewed allows for better usage
of the available time.
>
> Another issue is that any scheme relying on this kind of thing to work
>
> properly will never scale well to multiple processors.
>
>
Why not? Worked on BeOS..
BeOS didn't have the performance we have, but I digress.
At any rate, a construct that ties two threads together such that one has to
wait synchronously for the results of the other, will work fine on any
number of processors. However, it will only be able to execute on 1
processor at a time since both threads can't run at the same time.
So being able to run on a MP machine is a far cry from being able to exploit
an MP machine. Mutexes and locks are by their nature the enemies of
concurrent execution, and are limiters of overall performance. Use them with
caution and understand exactly what the ramifications are.
>
> This is a less than optimal situation no matter how you slice it. You are
>
> better off coming up with a scheme that doesn't require a lock.
>
>
I have one. But more things would be possible if you could just lock for a
>
few instructions.
It has been my experience that there is no such thing as a lock for just a
few instructions. Locking creates the need for the scheduler to decide what
thread runs next. Despite your best efforts, you will not be able to
guarantee that the scheduler makes the decisions you want it to 100% of the
time under all circumstances.
The reality is that you are running on a shared system capable of running
multiple threads simultaneously. Other processes will create threads that
will compete with yours. You have to design in a way that accounts for this
and delivers the results you are looking for.
--
Jeff Moore
Core Audio
Apple