Task-Mutex inter-dependency

eyalasko1 wrote on Tuesday, May 21, 2019:


Is there any constraint on acquiring (taking) mutex in Task A and releasing (giving) it back in Task B context ?
Same question for ‘ordinary’ (binary/counting) semaphore

It appears to generate hard-fault…


richarddamon wrote on Tuesday, May 21, 2019:

As I understand it, a Mutex is ‘Owned’ by the task that took it, and that Task is supposed to be the one that releases it. This is an effect of the Priority Inheritance that comes from Mutex which is the major reason to use a mutex over a semaphore for access control.

Since the reason for a mutex is to syncronize access to something shared, only that task really knows when it was done using it, so only that task can really give it. If some other task gives back the mutex before the one that took it, the taking task my continue to access the shared resource after some other task has aquired the mutex and is assuming it has exclusive access.

Semaphores fully support that sort of operation, in part that they have many other forms of uses, one in particular is that one task/ISR raises the semaphore (by giving) to signal to another task that it should do something (by its take succeeding). I use this quite often.

One thing to watch out for in this case is that both tasks have the handle to the same semaphore, these tend to be made ‘globals’ or need to be passed into the task through some sort of parameter system. An uninitialized handle is a good source of hard-faults.

eyalasko1 wrote on Wednesday, May 22, 2019:


I guess that timer task that terminates access to resource (giving mutex) falls within this category.

Thanks again.

richarddamon wrote on Wednesday, May 22, 2019:

Your comment isn’t clear to me, but if you are trying to implement something like a maximum hold time on a mutex, so that after the time is over the mutex is automatically released and the task no longer has access to the resource, that unfortunately isn’t really possible in a framework like FreeRTOS. Such a design is possible in a system with a much heavier design with independant processes (which might have multiple threads), but FreeRTOS is much lighter weight than that. In general, FreeRTOS has no way to enforce that the mutex was actually needed to access the resource, so no way to remove that access by removing the mutex. Thus there is no reason for a second task to release a mutex held by another task, so that is prevented.

The idea that some heavier systems have that allow for terminating or restricting some processes that aren’t behaving right doesn’t really work in FreeRTOS. Tasks aren’t really seperated enough to allow the external killing of a rogue process that doesn’t impact the rest of the system. In exchange for losing that ability, FreeRTOS is much lighter weight, and able to run on much lower end systems. Such limites need to be designed into the tasks, where perhaps a task at points in its processing checks how long it has been running, and if it has passed its design time, somewhat gracefully relinguishes its control over the resource.

eyalasko1 wrote on Thursday, May 23, 2019:

maximum hold time on a mutex, so that after the time is over the mutex is automatically released and the task no longer has access to the resource,

That’s exactly what I was asking… Thanks for clearing this out.