On Mon, Jan 16, 2012 at 3:43 AM, IOhannes m zmoelnig
<zmoelnig@iem.at> wrote:
i think there are 2 use cases for multi "threading".
#1 access a single instance of (lib)pd from multiple threads
#2 allow multiple instances of (lib)pd to co-exist in global memory.
That's right, and there are real use cases for both of them. An example of the former is the case I mentioned earlier, a libpd-based app with a GUI thread and an audio thread. An example of the latter are audio nodes in the jReality scene graph; it would be great to have one Pd instance per audio node.
right now, only #1 is possible at all and it takes some effort on the
"thread host" (the external) to not fuck Pd's heap.
i think Pd should be more helpful in this respect: a way to make Pd
thread-safe is to eliminate global variables and if they can't (or
shan't) be eliminate them properly protect them against parallel access.
As far as libpd is concerned, I would prefer not to have any synchronization inside Pd itself --- libpd can be used in a wide variety of settings, with lots of different approaches to concurrency, and so it's impossible to make any assumptions about threading at this level.
Of course, as you point out, Pd itself requires some synchronization in its interaction with externals, so there's a bit of a conflict there. My favorite solution would be to refactor Pd so that it has an audio library much like libpd at its core. Then Pd would be able to do all the synchronization it needs without affecting other applications that use the same library.
On
2012-01-14 22:04, Miller Puckette wrote:
> To do this I'd replace all globals like
API (like "pd_objectmaker") and provide accessor functions to get
(thread safe) access to them?
e.g. i would prefer if the symhash stayed global and instead access to
it (via gensym()) was thread safe.
I'd rather not have any shared global state at all because that would significantly reduce the possible performance gains from concurrency (Amdahl's Law).
i would rather _not_ tie the concept of "instance" to the concept of
"thread" (even though in practice they might often be interchangeable).
Agreed.
afaik, the usual way to accomplish a concept of multiple instances is to
aggragate all currently global variables into a "context" and extend the
API so that each function has an additional parameter for this context.
this will obviously break API compatibility...
The solution I have in mind would add an extended API that has a context parameter everywhere. In order to maintain compatibility with current code, there would be a global legacy context, and the functions in the current API would simply invoke their new counterparts with this global context.
anyhow, i would strongly suggest not to use some compiler magic that
might or might not be supported for older (and newer) compilers
available on the market for (lib)pd itself.
Agreed. Also, there has been talk of using libpd in embedded systems, which may come with exotic compilers of their own.
Cheers,
Peter