From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies-bounces@xxxxxxxxxxxxxxxxx]
On Behalf Of Malte Vesper
Sent: Thursday, March 26, 2015 10:50 AM
To: kernelnewbies
Subject: Re: Atomics and memory barriers
On a second thought:
Is it correct that atomic_set() without a writebarrier following it is still atomic (no torn writes), however not guaranteed to be visible to other threads?
On 26/03/15 17:47, Malte Vesper wrote:
Hello,
I have been reading up on atomics and struggle to grasp when exactly I need explicit memory barriers.
While the documentation (Documentat/atomic_ops.txt), talks about operations needing explicit barriers both sides, I assume this is only half true.
If I for instance only want to use an atomic as a flag to show that some operation is complete I reckon that a barrier before is sufficient.
Furthermore I found the following lines:
288 If a caller requires memory barrier semantics around an atomic_t
289 operation which does not return a value, a set of interfaces are
290 defined which accomplish this:
291
292 void smp_mb__before_atomic(void);
293 void smp_mb__after_atomic(void);
note how it refers to "operation which does not return a value", why can't I use these for atomic operations that do return a value?
What should I use instead, normal barriers like mb?
Please enlighten me
Malte
You might want to try reading Documentation/memory-barriers.txt.
It does a better job of explaining this stuff than atomic_ops.txt.
That being said, none of this stuff is easy to understand.
I’ve read both a few times and still don’t quite get all of it.
Good luck,
Jeff Haran
