-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify Tuner & Frequency Controller Locks to Avoid Thread Deadlock #1876
Labels
Comments
DSheirer
pushed a commit
that referenced
this issue
Apr 29, 2024
DSheirer
pushed a commit
that referenced
this issue
Apr 29, 2024
DSheirer
pushed a commit
that referenced
this issue
Apr 29, 2024
DSheirer
pushed a commit
that referenced
this issue
May 4, 2024
DSheirer
added a commit
that referenced
this issue
May 4, 2024
…#1901) Co-authored-by: sheirerd <sheirerd@ainfosec.com>
Closed
DSheirer
pushed a commit
that referenced
this issue
May 16, 2024
…ling and track history tail plotting adjustments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Application Log
20240313_115607_sdrtrunk_processing_diagnostic_report.log
The text was updated successfully, but these errors were encountered: