Changes between Version 13 and Version 14 of Projects/GSoC/Atomic_Operations

Timestamp:

08/14/12 18:58:21 (12 years ago)

Author:

WeiY

Comment:

Projects/GSoC/Atomic_Operations

@@ -111 +111 @@
 
  * 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.
+= Design of Atomic operations API =
+
+
+The first part is a directory structure chart, atomic.h is API definition file and cpuatomic.h is implementation file. 
+
+ |---/cpukit
+       |
+       |----score
+              |
+              |----include
+              |       |
+              |       ----rtems
+              |       |      |
+              |       |      ----score
+              |       |             |
+              |       |             ----atomic.h
+              |------cpu
+              |       |
+              |       ------architecture
+              |       |           |
+              |       |           -------rtems
+              |       |                     |
+              |       |                     ----score
+              |       |                           |
+              |       |                           ----cpuatomic.h
+              |       |                           |
+              |       |                           ----cpu.h
+
+Becuase most of the implementation of atomic operations are assembly instructions, if not they could also be implemented with inlilne C source code. So i place the architecture-independent atomic API definitions to the atomic.h which is visible to other rtems components like score, dirver and etc. The architecture-dependent atomic implementations are placed to the cpuatomic.h which exists in every architecture-related directory as show above. The API is associated with implementations using method like this: 
+for example, the atomic general load function API: int Atomic_Load_Acq_Int(volatile int *p)
+1. In the implementation file cpuatomic.h it will be implemented like this:
+   static inline int _Atomic_Load_Acq_Int(volatile int *p)
+   {
+       embedded assembly code;
+   };
+2. In the API definition file atomic.h it will be defined like this:
+   #define    Atomic_Load_Acq_Int(p)  _Atomic_Load_Acq_Int((volatile u_int *)(p))
+3. The cpuatomic.h should be included in the atomic.h directly or indirectly. If it is included in the atomic directly its file name should be fixed and each architecture has the same file name. If it is included in the atomic.h indirectly its file name can be unfixed and each architecture can have different file name, but it must be included by a architecture-dependent header file(like cpu.h as showed above) which can be included by architecture-independent score header file atomic.h 
+
+Synopsis:
+
+The follow is atomic operation API definition in "rtems" style:
+1. The atomic_store generic functions
+   void _Atomic_Store_Rel_<_type_>(volatile _type_ *p, _type_ v);
+2. The atomic_load generic functions
+   _type_ _Atomic_Load_Acq_<_type_>(volatile _type_ *p);
+3. The atomic_fetch-and-modify generic functions
+   void _Atomic_Fetch_Add_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
+   void _Atomic_Fetch_Sub_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
+   void _Atomic_Fetch_Or_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
+   void _Atomic_Fetch_And_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
+4. The atomic_compare_exchange generic functions
+   int _Atomic_cmpset_[acq_|rel_]<_type_>(volatile _type_ *dst, _type_ old, _type_ new);
+
+Description:
+
+1. _types_:
+
+Each atomic operation operates on a specific type.  The type to use is indicated in the function name.  The available types that can be used are:
+     int  unsigned integer
+     long unsigned long integer
+     ptr  unsigned integer the size of a pointer
+     32   unsigned 32-bit integer
+     64   unsigned 64-bit integer
+Because rtems is used in lots of soc with 8 or 16 bit bus, so some architectures can consider provide operations for types smaller than ''int''. In the FreeBSD only some architectures provide those types.
+     char  unsigned character 
+     short unsigned short integer
+       8   unsigned 8-bit integer
+      16   unsigned 16-bit integer
+
+2. Acq and Rel:
+     "Acq" represens a read memory barrier which ensures that the effects of this operation are completed before the effects of any later data accesses
+     "Rel" represens a write memory barrier which ensures that all effects of all previous data accesses are completed before this operation takes place
 = References =