[gmpi] Re: Topic 5: Threading
- From: "Ross Bencina" <rbencina@xxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 14 Apr 2003 01:27:30 +1000
[sorry, if this is a duplicate, i don't think it got through first time
around]
Vincent Burel wrote:
> > Can anyone give a good reason why DSP objects need to be callable from
> > multiple threads?
>
> yes i can ! :-)
>
> for example 3 thread can ask for datas access, related to processing
> 1- the GUI thread to modify parameters of the sound
> 2- the MIDI thread wich give the note On / Off event.
> 3- the Display thread wich ask for levels every 50 ms to display the
current
> metering values.
Presumably Angus means "callable simultaneously from multiple threads," as
requiring DSP objects to have thread affinity is a big deal - the object
must live its whole life in one thread - including creation and
destruction - It can't be migrated to a processing thread running on a
different processor in an SMP system, and so on.
Personally I think it is asking for trouble to expect DSP objects to manage
syncronisation. The best syncronisation primitives are lock free and
non-blocking, but implementing them in the multiple-reader/multiple-writer
case is non-trivial. I suspect many existing plugins don't use these
schemes, and hence don't guarantee non-blocking behavior, yet my own
expectation as a host writer is for DSP objects to not block the calling
thread (in the sense of making another thread runnable) when I call their
methods.
If syncronisation is left to the host, the host can make a decision whether
to put a fine-grained lock around each DSP object, to use a lock-free
message passing system, or some other approach. If syncronisation is left to
the plugin, then the host looses control of the threading environment,
unless the host can supply the plugin with implementations of the
syncronisation primitives (threads, locks, queues etc.) and potentially with
policies about how to use them.
So, I would suggest that DSP object should be callable from multiple
threads, but not simultaneously - ie they should not use thread-local
storage, but they should not be called re-entrantly from different threads.
Best wishes
Ross
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
