On 17/07/15 13:43, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote:
Attached is a more complete example.
I'd prefer not to share the two implementations, just copy and adjust
the linux/bar.[ch] into rtems/bar.[ch].
Ok, I understand that you want to separate support for a niche system from
the mainline Linux, but then I have to deal with all the problems involved
with copy and paste of source code, e.g. RTEMS would not automatically
profit from bug fixes and improvements of the Linux futex barrier.
As you can see from the history, the amount of changes in that area is not
all that big, the last change is from 2013 when cancellation has been added.
When a support for a new version of the standard is added (roughly every 2
years), the implementation needs to be tested and adjusted anyway. I'd
prefer not to have ifdefed code around in the Linux version, and the RTEMS
futex doesn't seem to be really similar to the Linux one (doesn't operate on
ints which contain the values).
The prototypes for the futex support are:
int _Futex_Wait( struct _Futex_Control *futex, int *uaddr, int val )
int _Futex_Wake( struct _Futex_Control *futex, int count )
The wait doesn't need the uaddr, since we don't have to search the futex
control structure.
BTW, dunno how large the _Futex_Control is, but if it is smaller than
64 bytes imnus 2 * sizeof(int), I'd suggest to put it right after the
generation field, at least in the Linux version the futex waiting/wakeup
is on the generation field in the first cache line, while it is expected
the second cache line is being changed independently.
Thanks for the hint. The size is 12 bytes on a 32-bit architecture.
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
