13 ms·
In audio code, I'd rather use a properly written wait-free SPSC queue, than a least-common-denominator messaging mechanism provided by the standard library like
by nyanpasu64 4y ago
In audio code, I'd rather use a properly written wait-free SPSC queue, than a least-common-denominator messaging mechanism provided by the standard library like postMessage() (where both the Win32 and JavaScript version suffer from contention and cause audio stuttering, see https://github.com/Dn-Programming-Core-Management/Dn-FamiTracker/pull/137 https://github.com/Dn-Programming-Core-Management/Dn-FamiTra... and https://blog.paul.cx/post/a-wait-free-spsc-ringbuffer-for-the-web/ https://blog.paul.cx/post/a-wait-free-spsc-ringbuffer-for-th...), though I'm not sure if generic channel/queue objects are as bad in practice. And message-passing (with anything other than primitive types) is a pattern for sharing memory that, if properly implemented and utilized (you don't send a pointer through a channel and access from both threads/goroutines), ensures no more than 1 thread accesses the object in a message at a time.
I think most but not all code can be constructed using primitives like (regular or wait-free) message queues and (RwLock or triple buffer) value cells, but I think all concurrent code which communicates with other threads of execution needs concurrent reasoning to design and write correctly. In my experience, Rust marking data as exclusive or shared is quite helpful for concurrent design and reasoning, whereas prohibiting shared memory altogether reduces performance drastically but is no better at correctness. I think message-passing merely shifts data race conditions into messaging race conditions (but perhaps Go is easier to reason about in practice than I expect). In fact, building programs heavily reliant on message passing between separate OS processes per service (like PipeWire) doesn't suffer from multithreading but rather multiprocessing and distributed systems, making it harder to establish consistent execution states or data snapshots at any point in time, or reason about invariants.
And even code not intended to communicate between threads needs to take care that no state is shared and mutated by another thread on accident (I concede this is easier with JS Web Workers or Rust which restrict shared mutability, than C++, Java, or Go which don't).
- samsquire 4y agoGo has a number of problems with regard to data races https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/ I think you need shared memory concurrency for performance. There are papers that argue for optimistic concurrency control and blocking concurrency control. Concurrency Control Performance Modelling Alternatives and Implications