Prototype implementation for self-contained objects

Gedare Bloom gedare at gwu.edu
Fri Jul 24 14:01:20 UTC 2015


On Thu, Jul 23, 2015 at 8:54 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> https://lists.rtems.org/pipermail/devel/2015-July/011989.html
>
> Its fully functional and well tested.  It is based on the FreeBSD support:
>
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-muteximpl.h
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-muteximpl.c
>
> It is used to implement the Newlib internal locks and the libgomp (GCC OpenMP
> support) operating system services.
>
> There is one issue I am not that happy about.  There are two thread queue
> definitions:
>
> 1. in Newlib <sys/lock.h>
>
> struct _Thread_queue_Queue {
>         struct _Thread_queue_Heads *_heads;
>         struct _Ticket_lock_Control _Lock;
> };
>
> 2. in <rtems/score/threadq.h>
>
> typedef struct {
>   Thread_queue_Heads *heads;
>
>   /**
>    * @brief Lock to protect this thread queue.
>    *
>    * It may be used to protect additional state of the object embedding this
>    * thread queue.
>    *
>    * @see _Thread_queue_Acquire(), _Thread_queue_Acquire_critical() and
>    * _Thread_queue_Release().
>    */
> #if defined(RTEMS_SMP)
>   SMP_ticket_lock_Control Lock;
> #endif
> } Thread_queue_Queue;
>
The only cost to remove the conditional is an extra 8 bytes per
Thread_queue? My intuition here is that non-SMP targets create few
enough of these queues that the overhead is not so bad. However,
analysis of the number of queues made in a base system would be good.

> In RTEMS the lock is optional.  In Newlib the storage must be always present
> for the lock to be independent of the actual RTEMS build configuration.  I
> ensure with static assertions that the layout of these two structures is
> compatible (see top of cpukit/score/src/mutex.c).  For the Newlib definition it
> would be sufficient to provide a structure with arbitrary content.  Only the
> alignment and size must fit (see glibc header files for objects shared by
> user/kernel space).  For debugging purposes it is quite handy to have an
> identical layout.  I use a cast to get the score definition, e.g.
>
> static Thread_queue_Queue *_Futex_Get_thread_queue(
>   struct _Futex_Control *futex
> )
> {
>   return (Thread_queue_Queue *) &futex->_Queue;
> }
>
> This may, however, lead to strict aliasing problems.  I am not sure how to
> solve this technically best.
Probably you can make futex._Queue a union of Thread_queue_Queue and
_Thread_queue_Queue.

>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list