On 21/12/17 16:48, Cudmore, Alan P. (GSFC-5820) wrote:
I like the idea of higher performance locking and the reduced need for error checking. We have had internal debates on how much error checking needs to be done when locking and unlocking a mutex for a shared data structure.
The main goal for this API is performance. There are absolutely no error checks. We have for example (SPARC, non-SMP):
00000000 <_Mutex_Acquire>: 0: 9d e3 bf 78 save %sp, -136, %sp 4: 91 d0 20 09 ta 9 Push stack and disable interrupts. 8: 86 10 00 01 mov %g1, %g3 Some nonsense from GCC. c: c4 06 20 0c ld [ %i0 + 0xc ], %g2 Load mutex owner. 10: 80 a0 a0 00 cmp %g2, 0 14: 12 80 00 07 bne 30 <_Mutex_Acquire+0x30> Check if mutex owner is NULL. 18: d4 01 a0 20 ld [ %g6 + 0x20 ], %o2 1c: d4 26 20 0c st %o2, [ %i0 + 0xc ] Yes, so load executing thread and store as new owner. 20: 91 d0 20 0a ta 0xa 24: 01 00 00 00 nop 28: 81 c7 e0 08 ret 2c: 81 e8 00 00 restore Enable interrupts and return (12 instructions in total). Here the trouble starts, the mutex owner is not NULL: 30: 03 00 00 00 sethi %hi(0), %g1 34: 82 10 60 00 mov %g1, %g1 ! 0 <_Mutex_Acquire> 38: c2 27 bf e4 st %g1, [ %fp + -28 ] 3c: 82 10 20 01 mov 1, %g1 40: c2 27 bf e0 st %g1, [ %fp + -32 ] 44: 03 00 00 00 sethi %hi(0), %g1 48: 82 10 60 00 mov %g1, %g1 ! 0 <_Mutex_Acquire> 4c: c6 27 bf dc st %g3, [ %fp + -36 ] 50: c2 27 bf fc st %g1, [ %fp + -4 ] 54: 96 07 bf dc add %fp, -36, %o3 58: 13 00 00 00 sethi %hi(0), %o1 5c: 90 06 20 08 add %i0, 8, %o0 60: 40 00 00 00 call 60 <_Mutex_Acquire+0x60> 64: 92 12 60 00 mov %o1, %o1 68: 81 c7 e0 08 ret 6c: 81 e8 00 00 restore 00000000 <_Mutex_Release>: 0: 9d e3 bf 78 save %sp, -136, %sp 4: 91 d0 20 09 ta 9 Push stack and disable interrupts. 8: d2 06 20 08 ld [ %i0 + 8 ], %o1 Load the thread queue head. c: d4 01 a0 20 ld [ %g6 + 0x20 ], %o2 Some nonsense from GCC. 10: 80 a2 60 00 cmp %o1, 0 14: 12 80 00 06 bne 2c <_Mutex_Release+0x2c> Check if some other threads wait (thread queue head != NULL). 18: c0 26 20 0c clr [ %i0 + 0xc ] Set the mutex owner to NULL. 1c: 91 d0 20 0a ta 0xa 20: 01 00 00 00 nop 24: 81 c7 e0 08 ret 28: 81 e8 00 00 restore Enable interrupts and return (11 instructions in total). Here the trouble starts, other threads wait for mutex ownership. 2c: c2 27 bf dc st %g1, [ %fp + -36 ] 30: 19 00 00 00 sethi %hi(0), %o4 34: 96 07 bf dc add %fp, -36, %o3 38: 98 13 20 00 mov %o4, %o4 3c: 40 00 00 00 call 3c <_Mutex_Release+0x3c> 40: 90 06 20 08 add %i0, 8, %o0 44: 81 c7 e0 08 ret 48: 81 e8 00 00 restore
Are these new APIs in addition to the classic RTEMS APIs for similar objects?
It is an addition to the Classic API with other design goals.
Since there are performance benefits, is there any reason to use the classic API over the self-contained objects?
The Classic API is a bit more robust against software errors, e.g. error status return vs. unpredictable behaviour.
Finally, the ticket referenced in some of the patches (2843) has a milestone of 6.1. Are the self-contained objects going in 5.1?
The objects are already there (since July 2015), the difficult part is to find proper names for the user API.
Thanks! Alan On 12/21/17, 9:19 AM, "devel on behalf of Sebastian Huber" <devel-boun...@rtems.org on behalf of sebastian.hu...@embedded-brains.de> wrote: Attached is the generated chapter with references.--Sebastian Huber, embedded brains GmbHAddress : Dornierstr. 4, D-82178 Puchheim, GermanyPhone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request.Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-- 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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
