Cherry Audio Forums

ColinP wrote: ↑Mon Aug 07, 2023 10:44 am But I think there is broad agreement that most problems with primitive shared-data are not serious because they either are self-healing, cause just a bit of noise or cause problems that are so rare as to present microscopic levels of risk.

There remains a fourth possibility - that primitive shared data types up to 64 bits in size are guaranteed to be handled in a thread-safe way, without having to worry about it, or explicitly code for it. Without knowing which bugs were detected and squashed during the development of VM (and VM 2), we don't know if third party developers are already shielded from this potential threat.

It might not be stated explicitly anywhere (I certainly can't find it), but it may in fact be the case. I guess the only people who can supply a definitive answer are Dan Goldstein and anyone else involved in the development of the VM infrastructure. Maybe a query on Kayako is in order rather than endless rounds of speculation amongst ourselves?

Steve W wrote: ↑Mon Aug 07, 2023 11:44 am With Java and VM is there a difference between audio bits and bytes being randomly lost and midi bits and bytes being randomly lost?

Steve, the same potential problems apply to any situation where multiple threads are interacting without the programmer taking into account synchronization issues. However, in most MIDI coding in VM everything is happening inside the ProcessSample() thread so there's nothing to worry about.

utdgrant wrote: ↑Mon Aug 07, 2023 12:30 pm There remains a fourth possibility - that primitive shared data types up to 64 bits in size are guaranteed to be handled in a thread-safe way, without having to worry about it, or explicitly code for it. Without knowing which bugs were detected and squashed during the development of VM (and VM 2), we don't know if third party developers are already shielded from this potential threat.

It might not be stated explicitly anywhere (I certainly can't find it), but it may in fact be the case. I guess the only people who can supply a definitive answer are Dan Goldstein and anyone else involved in the development of the VM infrastructure. Maybe a query on Kayako is in order rather than endless rounds of speculation amongst ourselves?

The 64 bit / 32 bit atomicity/volatility question is something specific to Java rather than Voltage Modular. Cherry Audio haven't created their own Java Virtual Machine they are using exactly the same technology as is available to everyone else.

CA have some clever people but they aren't going to replace or magically enhance technology that took Sun Microsystems and others decades to develop. The second paragraph of the VMD documentation...

Voltage Modules are written in Java, and all code is Java 8 SE compliant. All of the capabilities of the Java language are at your disposal, including multithreading, encryption, networking capabilities, and more. Voltage is powered by a highly optimized “hot spot” virtual machine that compiles the Java functions directly to machine language, so modules run at essentially the same speed as compiled native code.

This "hot spot" virtual machine isn't CA technology. They are referring to HotSpot. Note both Oracle and OpenJDK use the HotSpot JVM.

On the broader subject of thread-safety in Voltage Modular CA have already stated the following...

Cherryaudio Danny wrote: ↑Wed Jul 26, 2023 6:21 pm It is possible for notifications to come from the GUI thread, timer threads, and even the sound engine thread if adjustments are made to knobs within the ProcessSample() function. However, it is not recommended to modify knobs within the ProcessSample() function as this is a time-sensitive thread and GUI functions shouldn't occur within it.

But it's easy to figure this out anyway by running simple diagnostics. Also ProcessSample() must interrupt other threads because when Notify() blocks on calling a menu or dialog the audio engine doesn't stall.

I don't actually think there is much contention here. It's just a matter of judgement calls about how risky certain things are. I started the Threading Nightmares thread because the particular project I'm working on requires functionality that isn't available using the stock VoltageComponent classes and the thread-safety issue is not discussed in the VMD documentation when it ought to be, but I'm not advocating some kind of revolution or claiming that CA's code is rubbish or anything like that.

Quite the contary I'm a great admirer of CA and VM even though it often seems that I am highly critical of both. In comparison with developing for VCV Rack developing in VM is absolutely fantastic.

My goal for discussing this is trying to arrive at best practices. As I've said before, VM docs and examples don't mention threading concerns at all. Given that, it's reasonable to assume a developer wouldn't consider threading when building modules unless they notice a problem. If the problem was rare and intermittent, it might be missed or written off as a glitch. Admit it, we've all done it.

As both a user and a developer of VM modules, I want modules to be as solid as possible. To that end, developers need to be aware how much effort to put into potential threading issues, and to do that they need to know what they are. Do they only exist at the extreme boundaries? Are they something nearly every module should be concerned about?

CA has written many modules. It'd be interesting to get their thoughts, especially since they have access to the inner workings of VM.