There are a lot of dangerous situations that occur around priority inversion. Dynamically changing the priority is an almost sure way to trigger a deadlock due to priority inversion. It may be that the situation in your code will avoid any problems, but the generic solution will certainly trigger many problems.
One possible solution for your overall situation may be to create a top-priority task that sits dormant waiting for a signal (semaphore) to start the high priority computation you need. By being the highest priority in the system you will automatically get 100% of the CPU while the computation is in progress. Using a second task will give you the high priority compute without dynamically adjusting the priorities of other tasks.
Please elaborate on this. A deadlock necessarily requires two or more threads/tasks claiming at least two synchronization objects in a circular unresolvable fashion. As long as there is only one synchronization object involved, there can by definition not be a deadlock. Priority inversion is a form of starvation, which is not a deadlock. There is no inherent relationship between deadlocks and priority inversion. Please explain the above statement.
If Task A (low priority) posts a semaphore to wake Task B (high priority) but task B was waiting for something else (uart data perhaps), then Task A is permitted to continue running (becasue B is still waiting for the uart). Task A then raises its priority and then waits for the semaphore. It will deadlock. Changing priorities adds additional failure points to the normal priority inversion problem by adding explicit priority inversion to the mix. If you also consider that Task C could raise Task A’s priority then it just gets much worse.
Sorry, but that’s complete nonsense. If A is suspended on “a” semaphore (which one? The one it “posted” itself? I thought it “posted that to B?”), its own high pri won’t make a difference because it is suspended. Whoever has a chance to signal/give a semaphore (the term “posting” is rather uncommon weith respect to a semaphore) will be able to do so, at least with regard to A. In your scenario, B will happily run ever if its own pri is now lower than A’s, so if it’s up to B to release a resource that A now waits on, it certainly won’t be stopped by A.
If, however, A will wait on a semaphore that it can only post itself, that scenario is unaffected by its temporarily higher priority. It’s a self suspension similar to a task trying to claim a non recursive mutex twice.
Also, in your scenario, there is no occurrence of priority inversion as there are no muteces involved (which are the only synchronization primitives that address priority inversion explicitly).
I apologize, using semaphore in the example was incorrect. Also characterizing this as a priority inversion deadlock was also not correct.
The deadlock I was thinking of can be better explained with a task-notify. If A notifies B and then raises its priority before waiting for a return notification, the deadlock can occur. Using a semaphore which can only be claimed or released will not allow such a situation to occur.
If it actually WAITS for the return signal, that blocks it, so it’s priority doesn’t matter. Only if waiting means spin polling, which NO task should be doing, do you have an issue.