Re: IOProc limitations
Re: IOProc limitations
- Subject: Re: IOProc limitations
- From: James McCartney <email@hidden>
- Date: Tue, 19 Jun 2001 15:18:46 -0500
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.
I don't see why a SysBeep would be a problem.
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.
>
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..
>
The reason why is
>
that you are essentially tying two threads together as a single unit, which
>
effectively makes them a single thread.
No I have not. It is just a way to exclude certain critical sections.
They only act as a single thread for the duration that there is a collision
on the mutex. Which should be very short.
>
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.
--- james mccartney email@hidden <
http://www.audiosynth.com>
SuperCollider - a real time synthesis programming language for the PowerMac.
<
ftp://www.audiosynth.com/pub/updates/SC2.2.10.sea.hqx>