[PATCH] c-user: Add self-contained objects chapter

[Sebastian Huber]

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-bounces at rtems.org on behalf of sebastian.huber at embedded-brains.de> wrote:
>
>      Attached is the generated chapter with references.
>      
>      --
>      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.
>      
>      
>

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