* Paul E. McKenney ([email protected]) wrote: > On Sun, Jun 13, 2010 at 05:20:34PM -0400, Mathieu Desnoyers wrote: > > * Paul E. McKenney ([email protected]) 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 ? 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
