Mutex obtain with timeout

Joel Sherrill joel.sherrill at oarcorp.com
Thu Dec 18 15:38:22 UTC 2014



On December 18, 2014 5:18:31 AM PST, 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.

I don't know if there is or not. It is close to Christmas but I can try to email Burns and Wellings. I have met them both a few times and they gave usually been quick to answer.

Or we could send Hesham to their office hours .. Lol

>[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

--joel


More information about the devel mailing list