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 > barrier.
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.
