[PD-dev] soundfiler~ thread usage
giuliomoro at yahoo.it
Tue Apr 17 17:34:51 CEST 2018
I would discourage calling pthread_create() when sending an open message. pthread_create() comes with overhead associated with resource allocation, which makes it particularly unsuitable for real-time operation.
The sleeping threads are probably not causing a big performance overhead , however I see how having too many *active* threads at the same time would cause overhead because of the context switching due to the OS's round-robin scheduling. I *think* an improvement could be to have a small pool of threads belonging to all [soundfiler~] objects that you manage internally and allocate to the reading operations according to your priorities, but maybe it's more trouble than it's worth it?
On Monday, 16 April 2018, 02:12:59 BST, Miller Puckette <msp at ucsd.edu> wrote:
This might be OS-dependent - on linux at least, you can create all the
threads you want and have them sleep forever waiting on a mutex with no
performacne hit (as far as I know anyhow).
I dont know what the ramifications would be of starting up threads only
when a readsfi~ or writesf~ gets an "open" message - I don't think that would
cause problems except for the slight increase in complexity of the code.
On Mon, Apr 16, 2018 at 02:19:55AM +0200, Dan Wilcox wrote:
> I'm working on a project with 64 soundfiler~ objects which may or may not be used all at once. I've noticed in the debugger that the each object is using a thread after instantiation, even when not actually reading a file. Is this normal? If so, what's the reasoning? I'd think it would be better, resource-wise, to spin up a thread as needed. Does starting/joining a thread take too long and break determinacy?
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> Pd-dev mailing list
> Pd-dev at lists.iem.at
Pd-dev mailing list
Pd-dev at lists.iem.at
More information about the Pd-dev