[ltt-dev] [PATCH] fix the "unknown" case

[paulmck@linux.vnet.ibm.com (Paul E. McKenney)]

On Sun, Jun 13, 2010 at 05:36:05PM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> > On Sun, Jun 13, 2010 at 05:20:34PM -0400, Mathieu Desnoyers wrote:
> > > * Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> > > > On Thu, Jun 10, 2010 at 09:46:31PM -0400, Mathieu Desnoyers wrote:
> > > 
> > > [...]
> > > 
> > > (will reply to the rest in the individual patches)
> > > 
> > > > > Can we trust __sync_lock_test_and_set/__sync_add_and_fetch given that
> > > > > __sync_synchronize is broken ?
> > > > 
> > > > I don't know yet.  If it turns out that we cannot, then I will use some
> > > > form of global locking.  But the __sync_lock_test_and_set() do at least
> > > > generate instructions, unlike __sync_synchronize().  ;-)
> > > 
> > > I'm concerned about the fact that their synchronization primitives might have
> > > the assembly all with, except for the memory barriers.
> > 
> > OK.  How about if I used a hashed array of locks, indexed by a hash of
> > the cacheline number of the access in question?  Then the "unknown" case
> > doesn't depend at all on the __sync_ primitives.
> 
> I'm afraid this won't work with signal handlers. :-/ It would be a shame to have
> to make these primitives non-signal-safe just for the sake of the "unknown"
> arch. Or maybe it could make sense to disable signals around these, even though
> it will be really slow ?

Hmmm...

Maybe the right thing to do is to make the build fail in the "unknown"
case.  By the time we make this safe, the performance will be pretty
bad!

My thought is to simply not have the two "unknown" include files, so
that configuration dies when trying to copy them over.  Perhaps better
yet, have the two "unknown" include files have nothing but a #error
statement.  Seem like a reasonable approach?

							Thanx, Paul

> Thanks,
> 
> Mathieu
> 
> > 
> > 							Thanx, Paul
> > 
> > > Thanks,
> > > 
> > > Mathieu
> > > 
> > > > 
> > > > I will send two patches, one that incorporates your suggestions, and
> > > > another that removes sync_core().
> > > > 
> > > > 							Thanx, Paul
> > > > 
> > > > > Thanks,
> > > > > 
> > > > > Mathieu
> > > > > 
> > > > > > +
> > > > > > +#ifdef __cplusplus 
> > > > > > +}
> > > > > > +#endif
> > > > > > +
> > > > > > +#include <urcu/uatomic_generic.h>
> > > > > > +
> > > > > > +#endif /* _URCU_ARCH_UATOMIC_ARMV7_H */
> > > > > 
> > > > > -- 
> > > > > Mathieu Desnoyers
> > > > > Operating System Efficiency R&D Consultant
> > > > > EfficiOS Inc.
> > > > > http://www.efficios.com
> > > 
> > > -- 
> > > Mathieu Desnoyers
> > > Operating System Efficiency R&D Consultant
> > > EfficiOS Inc.
> > > http://www.efficios.com
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com