[PD-dev] soundfiler~ thread usage

[Giulio Moro]

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?
Giulio


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.

cheers
Miller

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
> https://lists.puredata.info/listinfo/pd-dev



_______________________________________________
Pd-dev mailing list
Pd-dev at lists.iem.at
https://lists.puredata.info/listinfo/pd-dev