This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp] Reuse futex barrier implementation for RTEMS
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 17 Jul 2015 13:43:11 +0200
- Subject: Re: [gomp] Reuse futex barrier implementation for RTEMS
- Authentication-results: sourceware.org; auth=none
- References: <55A8A347 dot 2010505 at embedded-brains dot de> <55A8E44C dot 7060500 at embedded-brains dot de> <20150717112642 dot GF1780 at tucnak dot redhat dot com> <55A8E815 dot 8050706 at embedded-brains dot de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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).
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.
Jakub