Subject: Re: [linux-audio-dev] Article about multithreading
From: Vincent Touquet (vincent_AT_ulyssis.org)
Date: Sun Jun 17 2001 - 11:48:22 EEST
Benno Senoner wrote:
> [cut] For example the finegrained multithreading model would probably work very
>
> well for lowlatency apps.
> Assuming that the threads are really scheduled in the way described in the
> paper (a context switch every few machine instructions).
> But of course in the realworld there are other issues like the presence of
> the opearating system etc.
Sure. Up till now Linux only supports one to one threads I guess ?
> > threaded code. Then we could toss multithreading overboard and start
> > coding giant balls of single threaded mud :).
>
> Although this can help, I don't think that this can match the human
> capabilities of splitting algorithms in separate threads.
I was only joking :)
Our analytic capabilities are indeed still much better.
Even though we aren't as good in raw floating point calculations.
> Conclusion: if you are planning to make a high performance audio app (eg you
> are going to need lots of CPU time), always design it with multithreading in
> mind. This allow your app to scale when run on multiprocessor boxes.
I think this is the right onclusion. Though some could say that not enough people
have MP boxes, so it is a 'useless' feature. (I don't agree with that)
> The drawback is that often designing a scalable multithreaded app is far from
> trivial, especially when you stuff (eg audio processing) that is not easily
> parallelizable.
Unfortunately, yes.
I was wondering: aren't there any toolkits 'out there' to simplify writing
multithreaded apps? (providing monitors for synchronisation etc.)
It would be difficult to design such a toolkit though as most of the code is very
application specific, with maybe the exception of locks / monitors for
concurrency / deadlock avoidance ?
Regards
Vincent
This archive was generated by hypermail 2b28 : Sun Jun 17 2001 - 11:41:10 EEST