From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [ltt-dev] [PATCH] fix the "unknown" case
Date: Sun, 13 Jun 2010 17:36:05 -0400 [thread overview]
Message-ID: <20100613213605.GJ5427@Krystal> (raw)
In-Reply-To: <20100613212807.GF2428@linux.vnet.ibm.com>
* 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 ?
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
next parent reply other threads:[~2010-06-13 21:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100610225242.GA21978@linux.vnet.ibm.com>
[not found] ` <20100611014631.GA13838@Krystal>
[not found] ` <20100611171613.GD2394@linux.vnet.ibm.com>
[not found] ` <20100613212033.GF5427@Krystal>
[not found] ` <20100613212807.GF2428@linux.vnet.ibm.com>
2010-06-13 21:36 ` Mathieu Desnoyers [this message]
2010-06-14 0:52 ` Paul E. McKenney
2010-06-14 2:08 ` Mathieu Desnoyers
2010-06-14 2:46 ` Mathieu Desnoyers
2010-06-14 5:11 ` Paul E. McKenney
2010-06-14 5:41 ` Paul E. McKenney
2010-06-14 17:04 ` Paolo Bonzini
2010-06-14 18:25 ` Paul E. McKenney
2010-06-15 8:52 ` Paolo Bonzini
2010-06-15 14:57 ` Paul E. McKenney
[not found] <20100614220600.GA15130@linux.vnet.ibm.com>
2010-06-15 12:35 ` Ulrich Weigand
2010-06-15 15:07 ` Paul E. McKenney
2010-06-15 15:18 ` Paolo Bonzini
2010-06-15 16:21 ` Paul E. McKenney
2010-06-15 16:07 ` Ulrich Weigand
2010-06-15 17:00 ` Paul E. McKenney
2010-06-15 17:03 ` Mathieu Desnoyers
2010-06-15 17:32 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100613213605.GJ5427@Krystal \
--to=mathieu.desnoyers@efficios.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox