bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SMP, barriers, etc.


From: Da Zheng
Subject: Re: SMP, barriers, etc.
Date: Sat, 26 Dec 2009 16:21:55 +0800
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)

Hi,

Samuel Thibault wrote:
> (I've cleaned To: and subject a bit :)
> 
> Da Zheng, le Wed 23 Dec 2009 21:23:23 +0800, a écrit :
>> Samuel Thibault wrote:
>>>> Is there anything else we should worry about?
>>> Ordering. See /usr/src/linux/Documentation/memory-barriers.txt
>> It's a long file. There are a lot to study:)
> 
> Yes, it's very instructive.
After I read this introduction, I checked some atomic operations implementation 
such as atomic_add_return in Linux for Aphla processors. Before and after these 
operations change the variable, they put memory barriers. So it's something 
like this:
smp_mb();
operations;
smp_mb();

But the problem is: on SMP, a variable's value can always been changed by 
another processor after the first memory barrier is called. Thus, the CPU does 
an operation on the stale value. There seems to be no way that we can guarantee 
that the variable has the latest value at the moment the CPU is doing the 
operation on it.
>> Does it mean all machines have to provide at least one instruction
>> that can modify variables in memory direct? so we can implement
>> spin_lock or something similar.
> 
> Yes. An architecture that wouldn't provide at least an atomic test and
> set would be a nightmare to program (just memory barriers is theorically
> enough, but it's a nightmare :) )
> 
So it's still doable. But I won't go deeper. Those algorithms can probably make 
my head explode:)

Zheng Da




reply via email to

[Prev in Thread] Current Thread [Next in Thread]