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.
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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
