Mutex obtain with timeout

[Hesham Moustafa]

On Thu, Dec 18, 2014 at 3:38 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> 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
>
Before I read this, I was about to reply that I can contact them faster :)
>>[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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel