Mutex obtain with timeout

[Gedare Bloom]

On Thu, Dec 18, 2014 at 8:18 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello,
>
> I work currently on concepts to implement mutex objects with SMP aware
> locking protocols.  Currently this is MrsP [1] and OMIP [2]. The
> implementation should use fine grained locking.  It turned out that the
> support for timeout makes the implementations much more complicated.  With
> timeouts you can tear a resource dependency tree into two sub-trees at
> arbitrary positions and this makes traversal difficult (you can cut off the
> way back).
>
> Is there a valid use case for a mutex obtain operation with a timeout in
> case the locking protocol aims to provide bounded wait times?  We can
> probably also assume that the critical section has a bounded execution time.
>
In general, I would suspect any "real-time" application that uses a
mutex with a timeout. I suppose you could construct a valid way to use
them, such as in a low-priority task that could lose the lock, and
thus 'checks' for the condition. Seems complicated to me though. It
may be sensible to remove the possibility of timeout altogether, at
least in SMP if we can support alternate bounds.

-Gedare

> [1] A. Burns , A. J. Wellings, A Schedulability Compatible Multiprocessor
> Resource Sharing Protocol -- MrsP, Proceedings of the 2013 25th Euromicro
> Conference on Real-Time Systems, p.282-291, July 09-12, 2013
>
> [2] Björn B. Brandenburg, A Fully Preemptive Multiprocessor Semaphore
> Protocol for Latency-Sensitive Real-Time Applications, Proceedings of the
> 2013 25th Euromicro Conference on Real-Time Systems, p.292-302, July 09-12,
> 2013
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel