From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Earnshaw To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: libstdc++/3584: arm-specific atomic operations not atomic Date: Thu, 12 Jul 2001 07:26:00 -0000 Message-id: <20010712142601.31998.qmail@sourceware.cygnus.com> X-SW-Source: 2001-07/msg00337.html List-Id: The following reply was made to PR libstdc++/3584; it has been noted by GNATS. From: Richard Earnshaw To: Robin Farine 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.