This is the mail archive of the
mailing list for the GCC project.
Re: [gomp] Reuse futex barrier implementation for RTEMS
- From: Torvald Riegel <triegel at redhat dot com>
- To: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Cc: gcc at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 17 Jul 2015 14:36:43 +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>
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
> On 17/07/15 13:26, Jakub Jelinek wrote:
> > On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >the libgomp configuration for RTEMS uses currently the POSIX
> >>> > >implementation. Unfortunately the performance is unacceptable bad, so I
> >>> > >work currently on a specialized RTEMS configuration. I would like to reuse
> >>> > >the code of the Linux futex barrier. On RTEMS there is no kernel/user
> >>> > >space separation. In order to make the futex management simpler, I would
> >>> > >like to optionally embed a futex object in the barrier. Would a change
> >>> > >like this be acceptable?
> >> >
> >> >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
I agree with Jakub. If your OS implements blocking differently than
Linux futexes, you are probably better off with a barrier implementation
whose blocking is designed for your OS' blocking mechanism.
How does your blocking mechanism work, roughly? Is _Futex_Control a
wake queue associated with the uaddr, basically? Perhaps something
along Java's park/unpark could be more natural for your OS. Or you
could even simplify the barrier implementation if you can check
arbitrary conditions, not just equality of a value and the futex word.