Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Date | 2011-05-13 12:47 +0200 |
|---|---|
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
| Newsgroups | comp.arch |
| Subject | Re: What are the various alternate uses for the PC's LSB ? |
| References | <9226d60e-0c97-4863-97ab-1fc568a7bb46@glegroupsg2000goo.googlegroups.com> <iqhv4i$bg8$1@speranza.aioe.org> <4DCCA664.9070207@SPAM.comp-arch.net> |
| Message-ID | <nqev98-qvt2.ln1@ntp6.tmsw.no> (permalink) |
Andy "Krazy" Glew wrote: > However, LL/SC is a mechanism that allows a lot of different > instruction sequences to be made atomic. You want > atomic-increment-with-saturation at [0,255] ... ? LL/SC can do that > for you. _Most_ of these can be handled equally well with traditional CAS (CMPXCHG*) semantics, it is only the ABA problem which is obviously easier to avoid with LL/SC. (earlier you wrote:) > Let alone a machine where you want to export the atomic RMW to the > interconnect, so that you can do NYU Ultracomputer style fetch and op > combining. Or, heck, even the simple form of RMW coalescing that > most GPUs provide. Personally I prefer algorithms which can use XADD, i.e. atomic fetch_and_add(), specifically because they can provide guaranteed forward progress, with minimum bus uglyness. It should also be relatively easy (for hw) to propagate an XADD operation across a mesh and handle it at the location of the target memory. It does mean that you have to allow the XADD - updated counter to wrap at whatever the natural size is, and handle any masking/special processing in the surrounding code. Saturation does not work in this scenario, since there's no easy way to get immediately back out of saturation: 253+, 254+, 255+, 255+, 255+, 255-, 254-, 253 (A workaround would be to detect that the current increment caused an overflow, then immediately decrement by that amount, but this can quickly get into race conditions against other threads. Having one or two secondary counters to record the amount of over/underflow could work, but that would make it much more complicated to read the current value. :-() Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: What are the various alternate uses for the PC's LSB ? "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-12 08:49 -0700
Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-13 02:01 +0200
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-12 20:32 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 12:47 +0200
Re: What are the various alternate uses for the PC's LSB ? Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-13 08:44 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 19:53 +0200
Re: What are the various alternate uses for the PC's LSB ? Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-13 11:36 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 22:26 +0200
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 17:17 -0700
Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-16 14:22 +0200
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-16 07:38 -0700
Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 17:14 -0700
Re: What are the various alternate uses for the PC's LSB ? rpw3@rpw3.org (Rob Warnock) - 2011-05-13 07:45 -0500
csiph-web