[cpp-threads] Yet another visibility question

Alexander Terekhov alexander.terekhov at gmail.com
Fri Jan 12 22:11:42 GMT 2007


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
> > >> 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.



More information about the cpp-threads mailing list