[PD-dev] threads

[Christof Ressi]

Hi,

> I get at least four threads
Just for some context: here on Windows I get 10 threads when I open Pd 
and start DSP, but only 2 of these are active and the remaining 8 or idle.

The Pd core itself does not spawn any threads, only the audio backend 
and certain objects/externals do (notably [readsf~] and [writesf~]).

But why do you care about the number of threads in the first place?

> As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? 
> I note that the other code in PD appears to use the sys_ringbuffer* 
> API, which seems to be built on the PA ringbuffer.
Is the PA ringbuffer considered trustworthy? Note that the ringbuffer 
code in "s_audio_ringbuf.c" - for whatever reason - is missing all the 
memory barriers from the original PA implementation. This happens to 
work as the implementation is in another source file and (non-inline) 
function calls act as compiler barriers and Intel has a strong memory 
model, but if compiled with LTO this code may very well fail on other 
platforms, particularly on ARM.

> I ask because I had some problems with z_ringbuffer.c and after a code 
> read, there are some bits which look sketchy enough to me that I 
> decided to stop using it.
Which problems did you have? And which bits look sketchy? There are some 
things that could be improved. The original code has been written before 
C11, i.e. before C/C++ got an official memory model. As a consequence, 
the platform specific atomic instructions / memory barriers are stronger 
than required. In general, SYNC_FETCH should really be called SYNC_LOAD 
and SYNC_COMPARE_AND_SWAP should be called SYNC_STORE. With C11, 
SYNC_LOAD could be just an atomic_load (with memory_order_acquire) and 
SYNC_STORE could be an atomic_store (with memory_order_release). Apart 
from that, the code looks fine to me.

Christof

On 11.04.2024 05:19, Caoimhe &co wrote:
> Hi y'all -
>
> I'm about hip deep in what is probably an ill-advised project,and I 
> have run into a situation where I am genuinely stumped. I am running a 
> build of PD 0.53.1 and I notice that regardless of the audio back end 
> I choose (between OSS, ALSA, and JACK, anyway) that I get at least 
> four threads (more with JACK, but that may be my own fault) running PD 
> on the latest AVLinux (based on MX, which is based on AntiX, which is 
> based on Debian).
>
> What's up with that? What are those four threads all doing? I ask 
> because I have only found the pthread_create that are in d_soundfile.c 
> (reasonable) and d_fft_fftsq.c; and it certainly seems like none of 
> those should be active just from starting up PD without even starting 
> up the DSP loop.
>
> As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? 
> I note that the other code in PD appears to use the sys_ringbuffer* 
> API, which seems to be built on the PA ringbuffer. I ask because I had 
> some problems with z_ringbuffer.c and after a code read, there are 
> some bits which look sketchy enough to me that I decided to stop using it.
>
> d/c/&cet
> -- 
> GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20240411/61006cf9/attachment.htm>