[fluid-dev] FluidSynth event queue and thread safety changes

[josh]

Hey David and list,

I finally got around to getting my event queue and thread safe related  
FluidSynth changes cleaned up.  I merged with the latest trunk and  
created a branch in SVN.  I did this because it is a lot of  
significant changes to fluid_synth.c and fluid_chan.c and thought it  
would be the easiest way to collaborate and track the changes.  I  
didn't want to commit it just yet to the main branch, in case of  
serious issues.  We should merge it soon though, to prevent too much  
divergence.

The current code builds, but I have not thoroughly tested it.

Change overview:
- Added fluid_event_queue.[ch] for the lockless FIFO event queue
- Cleanup of fluid_synth.c and fluid_chan.c
  + Functions used only in the local file set to static with  
declaration at top
  + All functions in fluid_synth.c documented
- Multi thread related documentation for each field of fluid_synth_t  
in fluid_synth.h
- Added _LOCAL variants of event related functions which can be called  
from the synth thread, the public versions check if queuing is  
required and queue or call the _LOCAL function as appropriate.
- Added functions for queuing MIDI, generator, float or integer events.
- fluid_synth_process_event_queue_LOCAL processes events sent to the queue.
- busy mutex renamed to "mutex" and used for many internal structures.


There are some issues with the API that we need to deal with, to make  
FluidSynth thread safe.  Here is what I have on my list so far:

These public functions should be called only from within the synth thread:
fluid_synth_nwrite_float
fluid_synth_process
fluid_synth_write_float
fluid_synth_write_s16
fluid_synth_alloc_voice
fluid_synth_start_voice
fluid_synth_get_voicelist

These functions can only be called if single threaded access is  
ensured (before synthesis starts for example):
delete_fluid_synth
fluid_synth_add_sfloader
fluid_synth_set_midi_router

I don't think that should be a problem for existing software.

TODO:
NRPN and RPN system per MIDI source (could conflict currently)
Make fluid_settings_t thread safe.

The following functions return instance pointers which could  
theoretically get freed at any time and are therefore currently  
problematic:
fluid_synth_get_preset
fluid_synth_get_channel_preset
fluid_synth_get_sfont
fluid_synth_get_sfont_by_id
fluid_synth_get_sfont_by_name
fluid_synth_find_preset

A possible solution without breaking the API would be to use unique  
IDs for fluid_sfont_t * and fluid_preset_t * and then use a hash table  
to lookup the actual instance (under a mutex lock).  Would need to  
analyze more though, to see if there are any other issues with that  
solution.

Many fluid_synth_t functions make use of ->mutex locks, therefore they  
must not be recursively called by other functions when holding the  
same lock (deadlock).

There are likely some additional issues with some fluid_channel_t  
fields and some fluid_synth_* functions.  Things are likely better  
than they were though, in regards to thread safety!

Here is the branch:
https://resonance.org/svn/fluidsynth/branches/fluidsynth_event_queue

Do let me know how I can help in regards to bringing you up to speed  
on my changes, etc.

Best regards,
Josh Green