Re: libstdc++/3584: arm-specific atomic operations not atomic

[Richard Earnshaw <rearnsha@arm.com>]

The following reply was made to PR libstdc++/3584; it has been noted by GNATS.

From: Richard Earnshaw <rearnsha@arm.com>
To: Robin Farine <acnrf@dial.eunet.ch>
Cc: Richard.Earnshaw@arm.com, robin.farine@terminus.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3584: arm-specific atomic operations not atomic 
Date: Thu, 12 Jul 2001 15:23:57 +0100

 acnrf@dial.eunet.ch said:
 > Besides the fact that the label "0:" should *precede* the "mov r2, 1"
 > instruction, this version too would allow starvation of a low-priority
 > thread. I suppose that a multi-threads and multi-processors safe
 > implementation of atomic_add() would look more like this: 
 
 I think we should forget multi-processor versions for the moment.  SWP 
 semantics don't work well with these, since SWP memory locations need to 
 be placed in uncached/unbuffered pages to have well-defined 
 multi-processor semantics.
 
 I'm not up on what threading models are usable with libstdc++-v3, so I'll 
 have to leave that side of things to the c++ library maintainers.