Prototype implementation for self-contained objects

[Joel Sherrill]

Is this intended for master only or also for the 4.11 branch?

On 7/23/2015 7:54 AM, Sebastian Huber 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;
>
> 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.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985