Sebastian Moors wrote: > I would go for the Fix which Torben Hohn suggested. That would be the > most "robust" solution.
It might be fine, but you also need to do it carefully so that you don't end up with deadlocks or reduced realtime performance. If you use a mutex separate from the main audio engine mutex, it's most likely safe, except you're risking a deadlock when two threads lock the audio engine and the get_instance mutex in the opposite order. Though deadlocks are usually easier to debug than race conditions. And if you use the audio engine mutex for guarding access to creating singletons, you're at risk of making _process function skip a buffer for completely trivial reason (like "because the GUI thread just happened to call Hydrogen::get_instance()"). This would be bad. Like gaps in the Ardour recording because of get_instance called from idle loop. You don't want that :) > We don't have to rely on the driver's code. The driver code still shouldn't start working until everything is prepared anyway. The most "proper" fix would be to start the worker threads (audio and MIDI) suspended, and unsuspend them only after audio driver stuff is ready. But that's a bit more complex change than what I and Torben have proposed (we're doing the same thing basically, only we rely on a mutex instead of suspend/resume for suspending the worked threads). Another thing to consider would be to avoid doing seriously complicated things (I'm talking about starting audio drivers here) in the constructor. This constructor may be invoked from more than one place (in fact, the first place that calls Hydrogen::get_instance()), and that means that control flow becomes unpredictable. Which means that theoretically simple bugs like #37 require a whole evening to find them. If starting audio drivers was moved out from constructor to separate function (called somewhere else in Hydrogen code, not from constructor), you could even create all the singletons at the start of the main() function without any obscure timing issues and without the need to use mutexes in get_instance everywhere (while preserving the same functionality AND safety). Sounds like win-win to me. > But this is just my theoretical opinion, maybe its total crap when it is > used in practice. Practice says that debugging multithreaded programs is quite hard. I have to do it on regular basis for Calf plugins (for obvious reasons) and for my daily job (where the number of threads is much higher than in any audio application, but there are no realtime requirements), and it's not fun at all. That's why I'm suggesting to "straighten out" the call graph a bit - see above :) Krzysztof ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
