From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 7 May 2011 20:25:25 -0400 To: 9fans@9fans.net Message-ID: <5d4e995cc83155be2adfaf18a9f44f68@ladd.quanstro.net> In-Reply-To: <20110507231019.298C0B827@mail.bitblocks.com> References: <30A0D4B5-1AAB-4D95-9B9F-FD09CB796E6D@bitblocks.com> <20110507231019.298C0B827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] _xinc vs ainc Topicbox-Message-UUID: e0e493d6-ead6-11e9-9d60-3106f5b1d025 > > the difference, and my main point is that the loop in ainc means > > that it is not a wait-free algorithm. this is not only sub optimal, > > but also could lead to incorrect behavior. > > I think a more likely possibility for the change is to have a > *copy* of what was incremented. lock incl 0(ax) won't tell you > what the value was when it was incremented. you can read the code. that value is not used by the thread library. > But I don't see how the change will lead to an incorrect behavior. could. imagine you have two threads entering ainc. the loser will loop. imagine that before the loser completes his loop a third thread enters aintr and becomes a two-time loser. by induction it's possible that the loser never completes in n loops for any given n. this of course is basically the definition of a waiting algorithm. if your program depends on time-bounded behavior from the thread library, you could have trouble with a non-wait-free algorithm like this. perhaps my concern is unfounded. i'd like to hear the argument. - erik