sdrtrunk Version
master

Describe the bug
RTL2832 based tuners use a ReentrantLock to control thread access to the hardware to deconflict automated processes and the user's ability to make minor changes. All tuners also employ a reusable FrequencyController to manage the currently tuned center frequency and sample rate and notifying consumers of changes, and this controller also employs a ReentrantLock. This can cause a thread deadlock when a tuner is disabled and the user enables the tuner again at the same time that a multi-frequency channel is rotating frequencies. Attached diagnostic log shows the two threads (21 and 67) in a dead-locked state where the channel is trying to get a new frequency channel source while the tuner is still in the process of initializing during restart. This is a rare use-case, but the existence of two locks within the same resource sets the stage for other deadlock scenarios.

1. Update the Tunable interface with a method to access the tunable's resource lock.
2. Update the base tuner controller to expose the ReentrantLock. The lock is currently in the RTL2832TunerController, but should be pushed up to the TunerController parent class to comply with the Tunable interface.
3. Update the FrequencyController to remove the ReentrantLock and instead use the lock from the Tunable member variable.

Application Log
20240313_115607_sdrtrunk_processing_diagnostic_report.log