> > 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. > > Yes, but if the GUI communicates directly with the DSP object, this will > require synchronization, since the GUI and DSP object can certainly be > running simultaneously from different threads. Do you force all GUI to DSP > object communication to go through the host?
I think so. I can think of a couple of ways this could work. The host could provide low-level syncronisation and/or messaging primitives (queues, locks, etc), alternately there could be a standard high-level GUI<->DSP object communication interface (message passing?) that the host provides an implementation of.
Bill Gardner wrote: > > 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. > > Yes, but if the GUI communicates directly with the DSP object, this will > require synchronization, since the GUI and DSP object can certainly be > running simultaneously from different threads. Do you force all GUI to DSP > object communication to go through the host?
I think so. I can think of a couple of ways this could work. The host could provide low-level syncronisation and/or messaging primitives (queues, locks, etc), alternately there could be a standard high-level GUI<->DSP object communication interface (message passing?) that the host provides an implementation of.
There is a book: "Real-time object-oriented modelling" by Bran Selic, et al. which describes an approach that uses objects (say our GUI and DSP objects) connected by message ports - all interobject communication is via asyncronous messaging through these ports - it strikes me as being a rather powerful approach.
A related issue concerns hidden sources of locks and thread-blocking such as memory allocation. I'm not really knowledgable about real-time memory allocation strategies, but I generally take the approach that allocating or freeing memory is not something that should be done in a real-time thread. If it is done in a real-time thread it should be done asyncronously, which is another use for a host-provided messaging service.
I'm trying to keep in mind what I said earlier about not tacetly specifying too much about the structure of the host - designing the plug involves co-designing the socket, but making sure the socket is just a connector, and not half an application is a real challenge.
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
---------------------- Bill Gardner Wave Arts, Inc. 99 Mass. Ave., Arlington, MA 02474 Tel: 781-646-3794 Fax: 781-646-7190 billg@xxxxxxxxxxxx
---------------------------------------------------------------------- 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
