Repository navigation
Dmod_Run: do not hold the module's mutex while its main() runs - #330
Merged
Merged
Conversation
Dmod_Run() kept Context->Mutex locked from before Dmod_Init() until after Dmod_Deinit(), i.e. for as long as the application runs. Everybody who locks it meanwhile - Dmod_BeginUsage() / _EndUsage(), Dmod_Enable(), ... - waited for the application to end, lending it their priority all the time (FreeRTOS mutexes inherit priority; it is given back only when the holder releases every mutex it holds): on dmod-boot every service started by systemd (priority 4) ran at 4 instead of its own DMOD_PRIORITY - a view being drawn by dmview starved an MP3 decoder of priority 2 (the car HMI played choppy). Found on the board: every service held one recursive mutex, its context's, at priority 4 over a base of 0 or 1. The mutex is released for Dmod_Main() and taken again for the deinit; Context->Running (set under it) still keeps a second Dmod_Run() out, and Dmod_Unload() still refuses a running module. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 of 3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Dmod_Run()heldContext->Mutexfrom beforeDmod_Init()until afterDmod_Deinit(), that is, for the whole time the application runs. Anyone who locks it in the meantime (Dmod_BeginUsage()/_EndUsage(),Dmod_Enable(), ...) waits for the application to end. Because FreeRTOS mutexes inherit priority, the holder runs at the waiter's priority until it releases every mutex it holds.On dmod-boot, systemd (priority 4) waits on it, so every service ran at priority 4 permanently instead of its own
DMOD_PRIORITY. A view drawn by dmview then starved the car HMI's MP3 decoder (priority 2), and playback crackled.This was found on the board: every service task held one recursive mutex, its context's, at priority 4 over a base of 0 or 1. With the fix, all tasks run at their base priority with no mutexes held, and playback is clean.
The mutex is now released around
Dmod_Main()and taken again for the deinit.Context->Running(set under the mutex) still keeps a secondDmod_Run()out, andDmod_Unload()still refuses a running module.Test plan
🤖 Generated with Claude Code