[yoshimi] Re: Mutex locks

  • From: Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx>
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Sat, 20 Oct 2018 08:36:19 +0100

On Sat, 20 Oct 2018 05:41:15 +0200
Ichthyostega <prg@xxxxxxxxxxxxxxx> wrote:

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?

Hi Hermann.

Your caution is well taken.

Originally, there was almost no buffering between various parts of the code,
and only two threads, with truly massive locks. Cal introduced some
buffering, and broke up the locks a bit with additional threads for MIDI.

These days, we now have *extensive* buffering and multiple threads. In
"dev_notes" there is a PDF of the overall structure called "ControlModel.pdf"

The absolute priority is the audio thread. At the start of each loop, this does
a round-robin check of all the input buffers to see if anything needs to be
changed. This is the only time anything can be written that affects audio, and
even then, only if the change can be made quickly. If it can't, the associated
section is disabled, and control passed to a low priority thread via another
buffer. This is how we manage to get completely silent whole patchset loads
while audio is running :)

Even the low priority threads are buffered from each other.

There is also a flag-based sort-of lock that delays reading data while a write
is actually taking place - to ensure threads don't get partially updated
information.

It's always possible that there are still bits we've missed. The last segfault
discovered was caused by starting multiple new instances when the main program
was itself first starting. This was my fault and due to crossing between the
new instance threads, and the main one - which (of course) are actually
separate. Auto instance starting had only just been implemented.

A very long-term fatality is where Yoshimi is configured for jack audio, but is
started when jack is not running *and* there is no available audio card. It
should revert to NULL audio, but nobody has had the time to investigate this :(

A known remaining non-fatal anomaly is where the GUI sometimes gets a window
partly scrambled. I suspect the cause is that there are still two routes to
update the GUI and very occasionally two calls can change the same element in
rapid succession - faster than FLTK can manage.

TLDR - it's much better than it was :)

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
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: