From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sat, 07 May 2011 20:25:25 EDT." <5d4e995cc83155be2adfaf18a9f44f68@ladd.quanstro.net> References: <30A0D4B5-1AAB-4D95-9B9F-FD09CB796E6D@bitblocks.com> <20110507231019.298C0B827@mail.bitblocks.com> <5d4e995cc83155be2adfaf18a9f44f68@ladd.quanstro.net> Date: Sat, 7 May 2011 18:24:40 -0700 From: Bakul Shah Message-Id: <20110508012440.923D3B827@mail.bitblocks.com> Subject: Re: [9fans] _xinc vs ainc Topicbox-Message-UUID: e0eb5662-ead6-11e9-9d60-3106f5b1d025 On Sat, 07 May 2011 20:25:25 EDT erik quanstrom wrote: > > > 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. If you want to use the value being atomically incremented, there is no more efficient way on x86. May not be used now but may be it can be used to make some synchronization primitive more efficient? > if your program depends on time-bounded behavior from > the thread library, you could have trouble with a non-wait-free > algorithm like this. Yes, but I think associating time-bounded behavior with any shared memory access is iffy. You always have this possibility on processors that provide nothing stronger than LL/SC (load-linked/stored-conditional).