linux/Documentation/atomic_bitops.txt
<<
>>
Prefs
   1=============
   2Atomic bitops
   3=============
   4
   5While our bitmap_{}() functions are non-atomic, we have a number of operations
   6operating on single bits in a bitmap that are atomic.
   7
   8
   9API
  10---
  11
  12The single bit operations are:
  13
  14Non-RMW ops:
  15
  16  test_bit()
  17
  18RMW atomic operations without return value:
  19
  20  {set,clear,change}_bit()
  21  clear_bit_unlock()
  22
  23RMW atomic operations with return value:
  24
  25  test_and_{set,clear,change}_bit()
  26  test_and_set_bit_lock()
  27
  28Barriers:
  29
  30  smp_mb__{before,after}_atomic()
  31
  32
  33All RMW atomic operations have a '__' prefixed variant which is non-atomic.
  34
  35
  36SEMANTICS
  37---------
  38
  39Non-atomic ops:
  40
  41In particular __clear_bit_unlock() suffers the same issue as atomic_set(),
  42which is why the generic version maps to clear_bit_unlock(), see atomic_t.txt.
  43
  44
  45RMW ops:
  46
  47The test_and_{}_bit() operations return the original value of the bit.
  48
  49
  50ORDERING
  51--------
  52
  53Like with atomic_t, the rule of thumb is:
  54
  55 - non-RMW operations are unordered;
  56
  57 - RMW operations that have no return value are unordered;
  58
  59 - RMW operations that have a return value are fully ordered.
  60
  61 - RMW operations that are conditional are unordered on FAILURE,
  62   otherwise the above rules apply. In the case of test_and_{}_bit() operations,
  63   if the bit in memory is unchanged by the operation then it is deemed to have
  64   failed.
  65
  66Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics and
  67clear_bit_unlock() which has RELEASE semantics.
  68
  69Since a platform only has a single means of achieving atomic operations
  70the same barriers as for atomic_t are used, see atomic_t.txt.
  71
  72