[yoshimi] Re: Mutex locks
- From: Ichthyostega <prg@xxxxxxxxxxxxxxx>
- To: yoshimi@xxxxxxxxxxxxx
- Date: Sat, 20 Oct 2018 05:41:15 +0200
On 10/17/18 11:06 PM, Will Godfrey wrote:
For nearly a year these have been disabled by default simply by making the
calls enter an empty function. No problems have shown up, so now all the
code and calls to it have been commented out. This should result in a very,
*very* tiny speed-up. We'll leave it like that for a while then eventually
remove them completely.
Hello Will,
please excuse my chiming in, but that statement raises some doubts for me. How
can we be sure that we don't need proper locking? Are we running single threaded
altogether? Where those locking calls added by people who didn't know what they
are doing? If mutexes are too slow (yes they are slow), wouldn't it be better to
come up with a solution based on atomics or similar modern techniques?
The problem is that you never get a clear indication when something breaks due
to improper locking. You can't expect that people will come up with bug reports,
simply because there won't be anything tangible to report. The application just
might behave weird randomly, on rare occasions. It might corrupt some numbers,
let some parameter suddenly jump to an outlandish value, put some UI state out
of sync, produce a sound glitch or hiss, suddenly deadlock the application or
just plain segfault.
And yes, yoshimi does all the above stuff, on rare occasions, and never
reproducible. Of course, we can not conclude anything about the reason,
and we know that there are lots of bugs in every X lines of code we write.
Personally, I have been hurt so badly in the past by my own juvenile attempts to
be clever and fast by omitting "unnecessary" and "overly zealous" locking, just
to squeeze out some % of speed. My conclusion is, it is never worth it. I have
seen code that obviously worked for years, just to suddenly break on a 16 core
machine, on a new OS version, on a virtual machine, or when ported from x86 to
ARM (which is way less forgiving in that respect).
Anyway, this is all just a general statement based on first principles, without
having looked into the code; I wasn't aware that there is an issue with
synchronisation in the codebase. Take it just as a caution notice.
-- Hermann
Yoshimi source code is available from either:
https://sourceforge.net/projects/yoshimi
Or:
https://github.com/Yoshimi/yoshimi
Our list archive is at:
https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx
Other related posts:
