On 06/09/2014 03:03 PM, Tobias Doerffel wrote: > Hi, > > this is a really tricky one and I would never have spotted it.. ;-) So > thanks for your efforts and your fix! > > In order to improve multi threading, we should think about either > adding a possibility where ThreadableJob::doProcessing() returns a > state flag. In case we're waiting for NPHs in an IPH we could simply > return "Waiting" or "Busy" so the IPH-ThreadableJob (instead of > processing all "children" serially in one thread) could be appended to > the job queue again and processed later. Alternatively we could > introduce processing priorities to ThreadableJobs so jobs with a > higher priority (NPHs) get processed earlier in the > MixerWorkerThreads. Any opinions? >
Well, I'm still quite unfamiliar with threading, in fact everything I know about threading is stuff I've learned while working on LMMS code... ;) So I'm not entirely familiar with all the intricacies, but from what I understand, threads "waiting in line" for things to process is something that should be avoided as much as possible, if we want to improve efficiency... correct? And that's also one reason why mutexes should be used sparingly, and only when necessary... So the priority thing sounds like the best option to me... but it should be done in a way where it's guaranteed that all "priority 0" jobs get processed first, before any "priority 1" jobs get started... otherwise we'll run again in the same problem. "Priority" could be an integer value, where "0" would be "process these first", and we could have as many levels as needed... then it could also be applied to the fx mixer, where multiple levels would likely be needed, and there we could keep track of the channel priority levels and only update them when channel send connections are changed. I have also other ideas about thread optimization: again working on the assumption that "waiting in lines is bad"... I've identified two places in the code where we're using a push model when a pull model would probably be more efficient: first is AudioPort. When multiple NPH's push their output into the shared AudioPort, they have to wait in a mutex because the writes have to be serialized, so this is probably inefficient? So to optimize this, we should probably do something where each NPH just gives the AudioPort a pointer to its buffer, and the AudioPort then pulls the buffers in and mixes them in a single thread. Another similar point is where instrument/sample tracks push their output to a mixer channel. If several tracks push to the same channel, there's another "wait in line" situation there, and we could apply the same kind of fix there too. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com _______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
