Phase-fair reader writer locks is a new class of reader-writer locks. Phase-fair rw lock has the following properties:

1.  Reader phases and writer phases alternate.
2.  Writers are subject to FIFO ordering, but only with regard to other writers.
3.  At the start of each reader phase, all currently-unsatisfied read requests are satisfied (exactly one write request is satisfied at the start of a writer phase) 
4.  And during a reader phase, newly-issued read requests are satisfied only if there are no unsatisfied write requests pending.

In some sense, phase-fair locks can be understood as being a reader preference lock when held by a writer, and being a writer preference lock when held by readers, i.e., readers and writers are “polite” and yield to each other. For example:

1.  T1-> thread1 issues a read request then satisfied.
2.  T2-> thread2 issues a write request then unsatisfied(because thread1 in read phase).
3.  T3-> thread3 issues a read request then unsatisfied(because thread2 writer already wait).
4.  T4-> thread4 issues a write request then unsatisfied(wait in FIFO order regard to thread2)
5.  T5-> thread1 releases read lock and then thread2 write request satisfied.
6.  T6-> thread5 issues a read request then unsatisfied.
7.  T7-> thread2 releases write lock and then thread3 and thread5 read request satisfied at the same time.
8.  T8-> thread3 and thread5 release their read lock, then thread1 write request satisfied. 

Reference:

1: http://www.rtems.org/ftp/pub/rtems/people/chrisj/source-builder/source-builder.html

2: http://concurrencykit.org/cgit/cgit.cgi/ck/tree/include/ck_pflock.h

The new atomic API draft design has been completed and the first version has been push into RTEMS mainline. Now the atomic ops implemenation is dependent on C11 stdatomic.h, so if the toolchain of some architecture does not support stdatomic.h it will not have atomic support(now it will post some error log when in the process of rtems compiling). And arm architecture can build successfully using atomic support. But sparc architecture lack of ‘cas’ instruction support in the toolchain. About this issue i have post a mail to gcc org atomic support for LEON3 platform and the gcc developer will consider add ‘cas’ support for LEON3.

Then i am working on the new atomic test case design. The first step is to provide some example about usage of atomic API. There is a good reference about atomic API design and test case design, Concurrency kit. It has support many atomic API and also provide lots of test case for according API. Becasue phase fair lock is very important for embedded system such RTEMS, i start port the phase fair lock test case from Concurrency kit to RTEMS. Now it has been completed, code is uploaded to github phase fair test case. There is still some problem about the printf under the SMP environment, i will try to make it work and submit to mainline.

Now lots of operation system have support their own atomic implementation. In the last year’s GSOC project i have also design atomic API for RTEMS and also ported the architecture-dependent implementation from FreeBSD to RTEMS. In the original design i have consider the roadmap of the atomic support for RTEMS, its first principle is to be easy to move to the C11 atomic implementation. Now it is time to move to C11 atomic because GCC4.8 and clang3.3 have supported this feature already.

My mentor Sebastian Huber have ported the stdatomic.h from FreeBSD to newlib. You can build it from the RSB(Rtems Source Builder). The build command is as follow (I build it not based on the latest RSB, If the latest RSB support stdatomic.h ignore me):

1
2
3
4
5

git clone git://git.rtems.org/rtems-source-builder.git
cd rtems-source-builder
patch -p1 < stdatomic-newlib.patch
cd rtems
../source-builder/sb-set-builder --log=l-arm.txt 1 --prefix=$HOME/development/rtems/4.11 4.11/rtems-arm

stdatomic-newlib.patch is as follow :

1
2
3
4
5
6
7
8
9
10
11
12
13

diff --git a/rtems/config/tools/rtems-gcc-4.8.1-newlib-cvs-1.cfg b/rtems/config/tools/rtems-gcc-4.8.1-newlib-cvs-1.cfg
index f39225d..458aa8b 100644
--- a/rtems/config/tools/rtems-gcc-4.8.1-newlib-cvs-1.cfg
+++ b/rtems/config/tools/rtems-gcc-4.8.1-newlib-cvs-1.cfg
@@ -7,7 +7,7 @@
 %include %{_configdir}/versions.cfg

 %define gcc_version    4.8.1
-%define newlib_version 31-May-2013
+%define newlib_version 15-June-2013
 %define mpfr_version   3.0.1
 %define mpc_version    0.8.2
 %define gmp_version    5.0.5

For mow information about RSB usage please refer the RTEMS Source Builder

If everything is ok you will see the toolchains have been installed under $HOME/development/rtems/4.11.

This week i have finished the new atomic API design and implementation for arm architecture based on the stdatomic.h. But now it is only working on SMP mode (tested on bsp realview_pbx_a9_qemu), the TODO list in later will be:

1.  Add the check to whether some architecture support stdatomic.h
2.  New test cased design.
3.  Other architectures support.

Today i have setup the github blog envrionment. Then i will record the progress and the detail of the GSoc project.

This year i will continue to doing the project “Atomic support for RTEMS”, my mentor is Sebastian Huber who is working on the ARM SMP support for RTEMS. And the Atomic support is very useful for SMP system. You can also reference the project wiki Atomic_Operations and my GSoc proposal Atomic Operations and SMP lock debug tool for RTEMS

I am looking forward and enjoying this summer!