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

[Peter Brinkmann]

Hi Chuck,
Check out the early bits of this thread --- various use cases already came
up along the way:
http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html.  The short
version is that libpd is being used in such a wide range of settings that
you can come up with legitimate use cases for pretty much anything (single
Pd instance shared between several threads, multiple Pd instances in one
thread, and anything in between).  At the level of the audio library, it's
impossible to make good assumptions about threading.



>
> I remember a conversation with IOhannes in August about
> multi-threading audio via sub-canvas user interface object (propose
> thread~ akin to block~).  If all you're after is audio
> multi-threading--there's no need for multiple instances of Pd.
> Threads could be used to start a portion of the dsp chain, running
> asynchronously, and then join/synchronize with Pd when finished.
>

I don't think a patch is the place where decisions about threading should
be made.  Threading is an implementation detail that users shouldn't have
to worry about, and besides, whether you have anything to gain from
threading will depend on a number of factors that users won't necessarily
be able to control or even know about.


> What this would look like:  Add a thread_prolog, thread_epilog, and
> thread_sync function. The thread_prolog function that occurs before
> block_prolog, starts a thread running the portion of dsp chain
> cointained within, and returns the pointer to the function following
> the thread_epilog.  The thread_epilog function that occurs after
> block_epilog--waits for synchronization and returns.
>

> What's the difficult part: You would need to have a good ordering of
> the dsp chain to take advantage of concurrency--each subcanvas having
> a thread~ object needs to kick off as early as possible, followed by
> objects that have no dependence on its output.  Secondly, you'd need
> to put thread_sync on the dsp chain immediately before you will
> encounter functions with data dependencies.
>

I believe it's much simpler than that.  It should be enough to just do a
topological sort of the signal processing graph; that'll tell you which
objects are ready to run at any given time, and then you can parallelize
the invocation of their perform functions (or not, depending on how many
processors are available).  I don't think there's any need to explicitly
synchronize much; tools like OpenMP should be able to handle this
implicitly.
Cheers,
     Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120125/79b0e1dd/attachment.htm>