__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Fri Jun 30 10:35:00 GMT 2017


On 30/06/17 11:26, Alexander Monakov wrote:
> On Fri, 30 Jun 2017, Richard Earnshaw (lists) wrote:
>> Sorry, but it's *VERY* different.  The options you mention will lead to
>> a consisten run-time failure.
>>
>> Getting the atomicity wrong will lead to random failures at runtime that
>> are almost impossible to track down due the nature of such race
>> conditions.  That's simply intolerable.
> 
> But our current solution in libatomic:
> 
> - may deadlock when atomic op is reentered via a signal frame;
> 
> - doesn't synchronize between distinct processes operating on
>   atomic objects in shared memory;
> 
>   (this can lead to the same failure mode as in your objection btw,
>   it might seem to work >99% of time);
> 
> - neither limitation appears to be documented in any obvious place.
> 
> 
> I'd say what we do now is far more inexcusable.
> 

These are both obvious limitations of objects that use locks.  Users
just have to be aware of such limitations.  Documentation would
certainly help.

Your solution spreads the chaos further to include multithreaded
programs with a single address space.  It doesn't solve any of the above
problems because some processes might still be using locks.

R.

> Alexander
> 



More information about the Gcc-help mailing list