wiki:Projects/GSoC/Atomic_Operations

Version 13 (modified by WeiY, on Aug 14, 2012 at 6:42:11 PM) (diff)

Atomic Operations

Mentors:

  • Chris Johns

Students:

  • Deng Hengyi

Status:

Introduction:

Candidate APIs / Implementations

Goal: To provide RTEMS with core services to solve synchronization problems on multicore platforms.

Requirements:

  • Advanced C and assembly language programming
  • Familiarity with RTEMS kernel software architecture
  • Understand concurrency problems and solutions

Resources:

Acknowledgements

References of atomic implementation

ConcurrencyKit?

A candidate for this project is the ConcurrencyKit? (ck). Among other targets, ck works on the 32-bit x86 architecture, so a first step would be to try compiling ck with rtems for pc386 and run a sample application under QEMU. Once a sample application is working, the next step would be to get as much of the ck regression suite to run as possible. Beyond that are many possible directions. Potential students should ask on the mailing list and work with potential mentors to design a project that suits their abilities and goals.

FreeBSD Atomic

The FreeBSD Atomic Operations API defines a set of atomic operations that can then be used to build solutions to concurrency problems. The FreeBSD implementations support a lot of target architectures, so there is more freedom to pick a starting point.

NetBSD Atomic

The NetBSD kernel implements seven classes of atomic memory operations. In the NetBSD kernel if the architecture provides compare and swap (CAS) each atomic operations is built on CAS. If the architecture does not provide hardware support for atomic compare and swap (CAS), atomicity is provided by a restartable sequence or by a spinlock.

C11 and C++11 Atomic

The end of 2011 brought new releases of both the C and C++ standards for the first time both of which contain a new set of atomic types and operations. The older versions of C and C++ had no support for atomic operations at all. The older versions of GCC and Clang provide the _sync_* family of built-in functions, which provide some atomic operations support. The GCC 4.7(or newer) and latest version Clang has provided built-in functions approximately match the requirements for C++11 memory model.

Linux Atomic

The Linux kernel mainly implements two class of atomic primitives: one without return value and the other with return value. In the Linux kernel any the 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).

Comparison of Atomic Implementation

In the proposal of Gsoc2012 project it has make a very detailed comparisons of all the above atomic implementations. Finally the atomic operations for RTEMS will refer the FreeBSD atomic implementations but the API design should contain most type of ISO C11 atomic definitions and follow its standard for API evolution.

Comparison of C11 and FreeBSD Atomic API definition

Through the comparison the C11 atomic API definition and the atomic API definition of FreeBSD kernel have the same or similar semantic. The functions not ending in _explicit in C11 atomic API have the semantics of their corresponding _explicit with memory_order arguments of memory_order_seq_cst in FreeBSD, So In there just list the API definition ending in _explicit.

  1. The atomic_store generic functions C1X: void atomic_store_explicit(volatile A *object, C desired, memory_order order); FreeBSD: void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);
  • FreeBSD API has the same semantic of C1X's API with memory_order arguments of memory_order_release.
  1. The atomic_load generic functions C1X:

C atomic_load_explicit(volatile A *object, memory_order order);

FreeBSD: _type_ atomic_load_acq_<type>(volatile _type_ *p);

  • FreeBSD API has the same semantic of C1X's API with memory_order arguments of memory_order_acquire.
  1. The atomic_fetch-and-modify generic functions C1X: (1)C atomic_fetch_add_explicit(volatile A *object, M operand, memory_order order); (2)C atomic_fetch_sub_explicit(volatile A *object, M operand, memory_order order); (3)C atomic_fetch_or_explicit(volatile A *object, M operand, memory_order order); (4)C atomic_fetch_xor_explicit(volatile A *object, M operand, memory_order order); (5)C atomic_fetch_and_explicit(volatile A *object, M operand, memory_order order); FreeBSD: (1)void atomic_add_[acq_|rel_]<type>(volatile _type_ *p, _type_ v); (2)void atomic_subtract_[acq_|rel_]<type>(volatile _type_ *p, _type_ v); (3)void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v); (4)void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
  • The FreeBSD API (1),(2),(3) have the same semantic of C1X's API (1),(2),(3) with memory_order arguments of memory_order_acquire or memory_order_release([acq_|rel_]). The FreeBSD API does not have the same semantic with C1X's API(4), but the FreeBSD API(4) is similar with C1X's API(5) where one uses &= the other uses &=~. So this part is easy to adapt. But all the FreeBSD APIs do not return value.
  1. The atomic_exchange generic functions C1X: C atomic_exchange_explicit(volatile A *object, C desired, memory_order order); FreeBSD: XXX NetBSD: _type_ atomic_swap_<type>(volatile _type_ *ptr, _type_ new);

  • The FreeBSD API does not support the atomic exchagne functions, but NetBSD has the similar semantic of C1X's API only with memory_order arguments of memory_order_relaxed.
  1. The atomic_compare_exchange generic functions C1X: _Bool atomic_compare_exchange_weak_explicit(volatile A *object, C *expected, C desired, memory_order success, memory_order failure); _Bool atomic_compare_exchange_strong_explicit(volatile A *object, C *expected, C desired, memory_order success, memory_order failure); FreeBSD: int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst, _type_ old, _type_ new);
  • In the FreeBSD Atomically compare the value stored at *dst with old and if the two values are equal, update the value of *dst with new. Returns zero if the compare failed, nonzero otherwise. In the C1X Atomically compares the value pointed to by object for equality with that in expected, and if true, replaces the value pointed by object with desired, and if false, updates the value in expected with the value pointed to by object.

References

  • TBD

Other sections: If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.