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: Wed, 11 Jul 2001 11:06:00 -0000 Message-id: <20010711180601.17556.qmail@sourceware.cygnus.com> X-SW-Source: 2001-07/msg00308.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: Wed, 11 Jul 2001 19:04:22 +0100 > This certainly works correctly but it would introduce another problem. If > another thread already holds the lock, the current thread would just spin > hopelessly until the thread that holds the lock gets the CPU and releases > it. This could result into a dead-lock if the spinning thread has a higher > priority than the lock owner. > > With the swap instruction (in contrast to test-and-set ;-)), I think that such > routines implementations have to depend on the threading model to explicitly > release the CPU when they fail to get the lock. Something like: Correct. I was forgetting that the load-locked/store-conditional operations wouldn't suffer from this problem. That makes the sequence particularly nasty, especially when called from thumb code... :-( R.