Project about Atomic Operations

[Gedare Bloom]

On Tue, Mar 27, 2012 at 3:27 AM, Ralf Corsepius
<ralf.corsepius at rtems.org> wrote:
> On 03/26/2012 06:19 PM, Thomas Doerfler wrote:
>>
>> Hi,
>>
>> I am a bit confused about this discussion. I havn't looked into the
>> RTEMS/GSOC project related to atomic support, but I agree with Sebastian
>> that it doesn't make sense to implement an RTEMS-specific atomic API
>> that would replace the C11 standard API.
>
>
> I agree in sofar as C11 could be a promise about an emerging, future
> standard.
>
> So far, IMO, C11 is too young to be considered stable and established
> standard and to be utilized as foundation of works.
>
> [Remember how long it took until comparable precessors (c89, c99) were
> stable and well established. Their implementation timeframes were measured
> in decades - I'd be surprised, if c11 would be different]
>
>
>> What might make sense is to
>>
>> - develop an API for RTEMS synchronization/kernel services which is ON
>> TOP of the C11 atomic standard
>
>
> One option I see, would be to treat c11-atomics as optional and conditional
> and to consider their API as API-template for RTEMS specific atomics.
>
>  This would mean, if C11 should be adopted for RTEMS, I'd recomment RTEMS to
> implement an RTEMS-specific wrapper layer, which optionally and
> conditionally may utilize c11-atomics as one potential implementation option
> underneath.
>
>
I said this already. Sebastian responded that adding yet another
atomics API seems iffy. I'm still mostly in favor of an RTEMS API
though, which could wrap the FreeBSD atomics or use C11 atomics or use
custom implementations of the ASM for targets supported by neither.

>> - develp support routines (maybe in newlib, maybe in RTEMS) that
>> implements a synchronization function.
>
>
> On a wider scope, I think, one would have to analyse whether c11-atomics
> actually meet RTEMS demands and ... whether lowlevel atomic operations are
> actually necessary and/or useful, rsp. if some atomics aren't better
> implemented on higher levels (e.g. using RTEMS score functions).
>
Atomic operations are necessary for good (correct) SMP performance. I
think the atomic operations will be used by score functions to
implement SMP-safe synchronization primitives (like mutex/semaphre),
so at the least the atomic ops API will co-exist with score functions.
I don't think we can implement the atomic operations using existing
score functions.

> At least I would rather avoid any low level, RTEMS-specific (esp. ASM)
> atomic operations, because such low level code in longer terms often turns
> into a nightmare.
>
Only ways to avoid this are to reuse someone else's implementation
(e.g. freebsd atomics) or to rely on C11 and push for atomic
operations support for the compilers and  CPUs we care about. I'm
thinking the right direction is to design a very thin RTEMS internal
API for atomic operations that wraps freebsd as an implementation
starting point and provides a C11 implementation for supported
processors. If C11 eventually supports all processors then the RTEMS
API can just wrap it.

-Gedare

>
>> Maybe for the discussion the following wiki page might help:
>>
>> http://gcc.gnu.org/wiki/Atomic
>>
>> It lists the architectures that GCC directly supports for atomics. All
>> other architectures (including ARM, M68K) require library support to get
>> atomic operations to work properly. So at least _this_ would be work
>> that requires doing.
>
> Well, IMO, The state Atomics in GCC currently is in speaks for itself.
> It's an Herculanean effort, which not even the GCC folks are able to
> implement on the broadness which would actually be required.
>
> Ralf
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users