RTEMS | Draft: cpukit: add support for common CAN/CAN FD stack (!49)

[Pavel Pisa (@ppisa)]

Pavel Pisa commented on a discussion on cpukit/dev/can/can-queue.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108461

 > +      rtems_mutex_lock( &inends->ends_lock );
 > +      rtems_mutex_lock( &outends->ends_lock );
 > +    } else {
 > +      rtems_mutex_lock( &outends->ends_lock );
 > +      if ( outends != inends ) {
 > +        rtems_mutex_lock( &inends->ends_lock );
 > +      }
 > +    }
 > +  } else {
 > +    RTEMS_DEBUG_PRINT( "Called with not fully connected edge\n" );
 > +    if ( inends ) {
 > +      rtems_mutex_lock( &inends->ends_lock );
 > +    } else if ( outends ) {
 > +      rtems_mutex_lock( &outends->ends_lock );
 > +    }
 > +  }

The locking has to be ordered to prevent deadlock and in general the graph can be more complex and the unique address of each entity is used to define global ordering of ends locking.
 
There is additional attempt to ensure unlock order to be precise reverse of the lock one for each case. This is not required when mutexes are used but when they are replaced by spinlocks with IRQ save then it is important.

It can have even some timing consequences but probably negligible. Original code looked much better but switch from Linux krenel or uLAN uLUt lists to newlib provided TAILQ makes code huge and original locking encapsulation problematic. TAILQ requires to provide matching pointer to head during remove and combined with lonking order requirements it is not nice. On the other hand it inlined and all tricky parts are seen in one go.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108461
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240628/dbe0353b/attachment-0001.htm>