[riot-notifications] [RIOT-OS/RIOT] core/mutex: Add mutex_cancel (#15442)

Marian Buschsieweke notifications at github.com
Sun Nov 15 10:17:55 CET 2020


> Maybe we should keep this somewhat internal, as in, advertise as supposed to be used only by system libraries or similar?

I don't think this will ease maintenance, if that is the intention. IMO it doesn't matter if we have to maintain this features due to it being used `xtimer_mutex_lock_timeout()` and `ztimer_mutex_lock_timeout()`, or because it is directly supported as public API.

In fact, the semantics of this function originally where different, but I had to change it in order to allow `xtimer_mutex_lock_timeout()` to be implemented on it. This is IMO a good indicator that the semantics is already set in stone due to the feature being exposed indirectly. So why not making it officially set in stone then.

(Originally only a currently blocked threads could be unblocked without obtaining the mutex, no "cancel ahead of time" was allowed. This was significantly easier to implement and faster. However, `xtimer_mutex_lock_timeout()` explicitly allows a timeout below `XTIMER_BACKOFF` and this is even checked in the unit test. IMO it would have been best to just fall back to `mutex_trylock()` for timeouts below `XTIMER_BACKOFF` and don't even bother with calling into `xtimer` at all for zero or near zero timeouts. But the semantics of `xtimer_mutex_lock_timeout()` have already been settled and I adapted `mutex_cancel()` to allow implementing this.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/15442#issuecomment-727539508
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20201115/16b96820/attachment.htm>


More information about the notifications mailing list