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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
-- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
