Project about Atomic Operations

Gedare Bloom gedare at rtems.org
Fri Mar 16 21:57:59 UTC 2012


On Fri, Mar 16, 2012 at 7:45 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
> Hi all:
>    The project of Atomic Operations seems a very good candidate for
> GSOC project. After some investigations i think its mainly goal is to
> define a set of atomic operation API and then implement those APIs. As
> we know an atomic operation is an operation that will always be
> executed without any other process being able to read or change state
> that is read or changed during the operation. From the software
> perspective a few of the synchronization primitives have
> implementations or examples of atomic operation like semaphores,
> mutexes , spinlocks and so on. And most of these synchronization
> primitives have been supported on the RTEMS. From the hardware
> perspective atomic operations mean a single instruction which will
> guarantee atomic access. And also the method of atomic operations is
> different for single core systems and multicore systems. In the single
> core systems we can just disable interrupt simplely to guarentee the
> atomic access, but in the multicore systems it does not work. So in
> there i think this project is mainly target at multicore support on
> RTEMS, right?
Yes, you have the right idea.

>    About the ConcurrencyKit it provide lots of atomic operations, but
> it does not natively support RTEMS. It must be ported to RTEMS. All
> the operations supported by ConcurrencyKit should be ported to RTEMS?
Well, the ck must be tested on a target architecture that RTEMS works
with (x86), and then we should attempt to integrate ck with RTEMS so
that the atomic operations and other parts of ck can be used. One
trick about this project is that we will want the atomic /
synchronization primitives available in the score, so the final
integration of ck would have to be treated with care.

FreeBSD and ConcurrencyKit both provide atomic operations. The FreeBSD
Atomic implementation may cover more RTEMS targets, whereas the
ConcurrencyKit may only have support for one RTEMS target, but ck
provides a number of interesting and useful algorithms that build on
the atomic operations. An advantage of the ck is that it is
self-contained which might make it easier to maintain.

> i think we can first design the needed atomic operation API and then
> implement API referring the ConcurrencyKit. And using the test case of
> ConcurrencyKit to test them. What is your opinions about this project,
> feel free to give your opinion.
>
Yes it might make sense to define an RTEMS-specific atomic operations
API that itself refers to atomic operations provided by another
package such as the ConcurrenyKit or a port of the FreeBSD atomic_xxx
functions.

> --
> Wei Yang
> Best Regards
>
> wei.a.yang at gmail.com
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users




More information about the users mailing list