Atomics and memory barriers

Atomics and memory barriers

[Malte Vesper]

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  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L288>  If a caller requires memory barrier semantics around an atomic_t
289  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L289>  operation which does not return a value, a set of interfaces are
290  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L290>  defined which accomplish this:
291  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L291>  
292  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L292>  	void smp_mb__before_atomic(void);
293  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L293>  	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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150326/581e805b/attachment.html 

Atomics and memory barriers

[Malte Vesper]

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  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L288>  If a caller requires memory barrier semantics around an atomic_t
> 289  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L289>  operation which does not return a value, a set of interfaces are
> 290  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L290>  defined which accomplish this:
> 291  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L291>  
> 292  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L292>  	void smp_mb__before_atomic(void);
> 293  <http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L293>  	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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150326/a9bea3d7/attachment.html 

Atomics and memory barriers

[Jeff Haran]

From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] 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<http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L288> If a caller requires memory barrier semantics around an atomic_t

289<http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L289> operation which does not return a value, a set of interfaces are

290<http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L290> defined which accomplish this:

291<http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L291>

292<http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L292>      void smp_mb__before_atomic(void);

293<http://users.sosdg.org/%7Eqiyong/lxr/source/Documentation/atomic_ops.txt#L293>      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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150326/ae28651e/attachment.html