----- Gedare Bloom <ged...@gwu.edu> schrieb:
> On Thu, Jul 23, 2015 at 8:54 AM, Sebastian Huber
> <sebastian.hu...@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.
You have one Thread_queue_Queue per object which allows a thread to block. If
we use an MCS lock instead of the ticket lock, then the overhead is only 4
bytes.
>
> > 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.
The Thread_queue_Queue is not visible in Newlib. One option would be something
like this
typedef union {
struct _Thread_queue_Queue Newlib_queue;
Thread_queue_Score_queue Score_queue;
} Thread_queue_Queue;
I think one way to avoid the strict aliasing problems is to define a seconds
set of the structures defined by Newlib <sys/lock.h> in the score and simply
cast to the score structure on function entry and never use the Newlib type.
--
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
