[cpp-threads] Yet another visibility question

[Alexander Terekhov]

On 1/12/07, Alexander Terekhov <alexander.terekhov at gmail.com> wrote:
> On 1/12/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> > On Fri, Jan 12, 2007 at 09:03:50PM +0100, Alexander Terekhov wrote:
> > > On 1/12/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> > > [...]
> > > >> Think of implementing SC  with per-variable locks on a large x86/IA32

Think of implementing SC for atomic<> (atomic_blah_blah in C speak)
with per-variable locks on a large x86/IA32

> > > >> NUMA configuration with multiple FSBs or whatever. It won't be any
> > > >> better than cmpxchg for loads and xchg for stores (both locked).
> > > >
> > > >My understanding is that locking is only guaranteed to force SC execution
> > > >of critical sections when all of the critical sections of interest
> > > >are guarded by the same lock.  Therefore, per-variable locks will not
> > > >necessarily force SC execution of all accesses.
> > >
> > > Give an example (for x86/IA32).
> >
> > I will start with a blatant example to make sure that we are really
> > talking about the same thing.  So, for a starting point using Linux-kernel
> > notation:
> >
> > o       Shared data:
> >
> >        DEFINE_MUTEX(mutex1);
> >        DEFINE_MUTEX(mutex2);
> >        int a = 0, b = 0, c = 0;
> >
> > o       Thread 1:
> >
> >        mutex_lock(&mutex1);
> >        a = 1;
> >        b = 1;
> >        mutex_unlock(&mutex1);
> >
> > o       Thread 2:
> >
> >        mutex_lock(&mutex2);
> >        c = 1;
> >        mutex_unlock(&mutex2);
> >
> > The two critical sections do not exclude each other, so could overlap
> > arbitrarily.  In this example, you would actually be worse off with
> > locks than with per-variable cmpxchg.
> >
> > Or am I missing your point?
>
> Give an example with assert().
>

regards.
alexander.