lkml.org 
[lkml]   [2017]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document
On Mon, Jun 12, 2017 at 04:49:29PM +0200, Peter Zijlstra wrote:
[...]
> -Any atomic operation that modifies some state in memory and returns information
> -about the state (old or new) implies an SMP-conditional general memory barrier
> -(smp_mb()) on each side of the actual operation (with the exception of
> -explicit lock operations, described later). These include:
> -
> - xchg();
> - atomic_xchg(); atomic_long_xchg();
> - atomic_inc_return(); atomic_long_inc_return();
> - atomic_dec_return(); atomic_long_dec_return();
> - atomic_add_return(); atomic_long_add_return();
> - atomic_sub_return(); atomic_long_sub_return();
> - atomic_inc_and_test(); atomic_long_inc_and_test();
> - atomic_dec_and_test(); atomic_long_dec_and_test();
> - atomic_sub_and_test(); atomic_long_sub_and_test();
> - atomic_add_negative(); atomic_long_add_negative();
> - test_and_set_bit();
> - test_and_clear_bit();
> - test_and_change_bit();
> -

The bit related operations are removed from memory-barriers.txt, I think
we'd better add them in atomic_t.txt? By "them", I mean:

test_and_{set,clear,change}_bit() as RMW atomic

{set,clear,change}_bit() as non-RMW atomic

test_and_set_bit_lock()
clear_bit_unlock() as non-RMW(but barrier-like) atomic

Regards,
Boqun
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-07-12 14:54    [W:0.119 / U:5.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site