ChibiOS Free Embedded RTOS

Something like return chThdGetSelfX() == mutex.owner .

This is useful in designing APIs where you want to lock down an entire module. You would do something like module_lock(), call a bunch of module_api() functions (each of which checks to make sure the calling thread owns the mutex), and then at the end do a module_unlock().

I haven't seen anything in the Chibi Mutex API that would enable this.

Wouldn't recursive mutexes help with that? when enabled a thread can take the same mutex multiple times.

Giovanni

Giovanni wrote:Wouldn't recursive mutexes help with that? when enabled a thread can take the same mutex multiple times.

Giovanni

Recursive mutexes are useful, but not in the scenario described. I want to ensure thread-safety between multiple of a module's API calls. In order to do that, I need to take a mutex, and then in each API call check if the calling thread owns the mutex. If it doesn't own it, it returns in error.

The specific use is case is of a file-like object, shared between multiple threads ... which has methods like lseek, read, and write. As an example, I want to do an lseek followed by a read - and ensure that no other thread modifies the file offset (via lseek) between the lseek and read.

Wouldn't this be an use case for chMtxTryLock()? You try locking, if it is not locked then you lock the mutex else you get an error without waiting.

Giovanni

Giovanni wrote:Wouldn't this be an use case for chMtxTryLock()? You try locking, if it is not locked then you lock the mutex else you get an error without waiting.

Giovanni

No, if it is not locked - then I want to return in error. I want to ensure thread safety between several module API calls - thus the module has to already be locked by the calling thread before calling the module API functions.



Each of the module_apix() functions check if the mutex is already owned by the calling thread. If it is owned by the calling thread, the function proceeds. Otherwise returns in error.

There could be other applications as well to check if the current thread owns a mutex. I think it's a small change - hence filed in small change requests .

As workaround you could unlock in case the try is successful. Adding a new functions should not be a problem, the code is there already.

Giovanni

Giovanni wrote:As workaround you could unlock in case the try is successful. Adding a new functions should not be a problem, the code is there already.

Giovanni

Yes, that would work as a work around for now. Thanks! Once this is implemented, it can be used in the HAL to enforce the xxxAcquireBus() and xxxReleaseBus() API with an assert (by making the public functions check for mutex ownership). As it is, it is not enforced and can lead to weird behavior since many functions are not thread safe.

bump

Hi,

Added as chMtxGetOwnerI().

Giovanni