[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

[Peter Brinkmann]

On Mon, Jan 16, 2012 at 3:43 AM, IOhannes m zmoelnig <zmoelnig at 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
>
> what is wrong with eliminating all directly accessible globals from the
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120119/74b3b15c/attachment.htm>