[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