[gomp] Reuse futex barrier implementation for RTEMS

[Sebastian Huber]

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.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.