Transition to C11 atomics and memory model

[Chris Metcalf]

On 9/15/2014 11:59 AM, Carlos O'Donell wrote:
>> * How do we deal with archs such as older SPARC that don't have CAS and
>> >other archs without HW support for atomics?  Using modified algorithms
>> >should be the best-performing option (eg, if we can use one critical
>> >section instead of a complicated alternative that uses lots of atomic
>> >operations).  However, that means we'll have to maintain more algorithms
>> >(even if they might be simpler).
> No. Stop. One algorithm. All arches that can't meet the HW support for
> atomics must enter the kernel and do the work there. This is just like hppa
> and ARM do. They use a light-weight syscall mechanism and serialize in the
> kernel.

Agreed!  And, tilepro is also on that list of platforms with weak atomics that uses a light-weight syscall to serialize in the kernel.  (Unlike tilegx, which has fairly rich atomics.)

On 9/15/2014 12:51 PM, Joseph S. Myers wrote:
> * In some cases those macros are defined by GCC even though the operations
> are out of line in libgcc.  On PA the HAVE_sync_compare_and_swap* macros
> are defined in pa-linux.h to cause __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* to
> be predefined; for Tile GCC has special target-specific code to define
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_*.  Do we believe such out-of-line libgcc
> versions will work in glibc, and is it preferable to use them or inline
> asm?

Yes, the tile out-of-line versions should work fine in glibc.  The tilepro out-of-line atomics do the lightweight syscalls.  On tilegx out-of-line support is only used for 1- and 2-byte atomics, which are not supported in hardware, so the out-of-line code does a 4-byte compare-and-exchange loop to synthesize the operation.  However, I suspect we are also not using those sizes in glibc itself - or if we are, we might decide we don't want to be.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com