Project about Atomic Operations

[Gedare Bloom]

Hi Wei,

You seem to have a fair grasp on the basics of this project. I see a
few basic phases in this project:
1) Design support for atomic operations usable by RTEMS score. This
involves creating an RTEMS internal API for atomic operations that is
not CPU-specific. Because of the varied hw requirements something like
the cache manager might be a good candidate to copy from, for example
something like an Atomic Operations Manager that has a similar
software architecture as the Cache Manager might satisfy our needs.
2) Implement default stubs (nops) for the API.
3) Write simple test code that uses the API (stubs). Tests should run
on all RTEMS targets.
4) Submit code and documentation.
5) Implement the atomic operations for a particular CPU. Document
procedures for implementation.
6) Test.
7) Submit.

With step 5 you might be able to borrow code from FreeBSD or
ConcurrencyKit or some other appropriately-licensed software. If you
keep the ConcurrencyKit/FreeBSD atomic operations implemif you keep
the ConcurrencyKit/FreeBSD atomic operations implementations in mind
as you design the Atomic Operations Manager this step may be
straightforward.entations in mind as you design the Atomic Operations
Manager this step may be straightforward. Once you complete through
step 7 you can also consider how to integrate the full ConcurrencyKit
with the RTEMS Atomic Operations Manager to provide some useful
synchronization tools that use the atomic operations.

-Gedare

On Sat, Mar 17, 2012 at 11:53 AM, Yang Wei <wei.a.yang at gmail.com> wrote:
> 在 2012-3-17，5:57，Gedare Bloom <gedare at rtems.org> 写道：
>
>> 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.
> OK, that means I understand what problem this project will solve and under what environment. It is mainly for the multicore systems in which the atomic operations are mostly relied hardware architecture instruction support. So first we should select a architecture like x86 or ppc which support the atomic operation instruction. Then we should try to integrate the ck into the RTEMS (as gedare said the atomic primitives should be in the score, so we should discuss the detail of this step.). At the same time we should also design and define the atomic primitives API used by RTEMS, this step we can refer the FreeBSD and NetBSD (NetBSD has good support for SMP, so we can spend time investigating its API definition and design). I will write a proposal for this project. f you have any comment, please feel free to contract me.
>>
>>>    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
>