Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #4284 > unrolled thread
| Started by | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| First post | 2011-10-20 19:51 +0000 |
| Last post | 2011-10-26 14:12 -0700 |
| Articles | 20 on this page of 175 — 34 participants |
Back to article view | Back to comp.arch
big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-20 19:51 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-20 22:35 +0200
Re: big-little Mark Thorson <nospam@sonic.net> - 2011-10-20 14:18 -0800
Re: big-little nmm1@cam.ac.uk - 2011-10-21 07:54 +0100
Re: big-little David Kanter <dkanter@gmail.com> - 2011-11-09 01:06 -0800
Re: big-little nmm1@cam.ac.uk - 2011-11-09 11:07 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 09:25 +0200
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-21 11:07 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-21 16:28 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-21 17:07 +0100
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-21 13:25 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-21 19:45 +0000
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-22 14:44 -0400
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-22 16:57 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-22 17:40 +0100
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-23 14:39 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-23 16:11 +0100
Re: big-little ChrisQ <meru@devnull.com> - 2011-10-23 17:44 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-23 18:46 +0100
Re: big-little Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-10-23 19:30 +0100
Re: big-little nmm1@cam.ac.uk - 2011-10-23 19:59 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-23 13:21 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-23 20:38 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-23 22:38 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-23 17:56 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-24 07:58 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-24 16:34 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-25 08:09 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-25 14:52 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-25 17:28 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-25 13:06 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-25 15:22 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-25 19:47 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 08:09 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-26 12:06 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-26 10:47 +0100
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-26 11:58 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-26 10:44 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 03:45 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 11:45 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 09:15 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 12:51 -0700
Re: big-little Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-26 11:45 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-26 15:42 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 09:07 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 12:53 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-26 21:05 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:20 -0700
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-26 17:55 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 09:10 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 01:34 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 10:29 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 04:28 -0700
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-27 12:22 -0400
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-27 18:08 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 11:50 -0700
Re: big-little Jean-Marc Bourguet <jm@bourguet.org> - 2011-10-27 14:10 +0200
Re: big-little nmm1@cam.ac.uk - 2011-10-27 17:58 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:15 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 04:10 -0700
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-27 14:04 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-27 23:07 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 15:58 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-27 22:57 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-27 16:39 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-28 00:16 +0000
Re: big-little nmm1@cam.ac.uk - 2011-10-28 09:52 +0100
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-28 07:01 -0700
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-28 16:45 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-29 13:13 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-30 03:36 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-30 03:55 -0700
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-28 11:15 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-28 20:01 +0100
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-29 17:46 +0000
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-29 11:30 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-29 20:02 +0100
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-10-29 13:09 -0700
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-29 17:42 -0700
Re: big-little nmm1@cam.ac.uk - 2011-10-30 08:16 +0000
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-11-04 10:06 -0700
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-11-04 15:19 -0700
Re: big-little nmm1@cam.ac.uk - 2011-11-05 09:13 +0000
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-11-05 09:03 -0700
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 13:38 -0700
Re: big-little Robert Wessel <robertwessel2@yahoo.com> - 2011-10-26 18:44 -0500
Re: big-little Michael S <already5chosen@yahoo.com> - 2011-10-26 17:05 -0700
Re: big-little Robert Wessel <robertwessel2@yahoo.com> - 2011-10-26 21:03 -0500
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 14:37 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 15:38 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-10-26 16:06 -0400
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-27 00:15 -0700
Re: big-little Morten Reistad <first@last.name> - 2011-11-03 17:30 +0100
Re: big-little "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-11-03 20:45 -0700
Re: big-little Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-11-04 11:13 +0000
Re: big-little MitchAlsup <MitchAlsup@aol.com> - 2011-11-04 10:12 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-04 09:26 -0700
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-11-05 11:32 -0400
Re: big-little EricP <ThatWouldBeTelling@thevillage.com> - 2011-11-05 11:55 -0400
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 09:58 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-05 18:39 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 15:00 -0700
Re: big-little wclodius@lost-alamos.pet (William Clodius) - 2011-11-05 18:43 -0600
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-05 19:46 -0700
Re: big-little ChrisQ <meru@devnull.com> - 2011-11-11 12:31 +0000
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 12:39 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-11 13:28 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 18:03 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-12 18:25 +0100
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-12 12:02 -0700
cost of prolog/epilog (was: big-little) Kalle Olavi Niemitalo <kon@iki.fi> - 2011-11-12 22:57 +0200
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-12 22:47 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-14 09:45 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-14 12:28 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-15 16:48 +0000
Re: cost of prolog/epilog Stefan Monnier <monnier@iro.umontreal.ca> - 2011-11-15 21:35 -0500
Re: cost of prolog/epilog Bakul Shah <usenet@bitblocks.com> - 2011-11-16 02:41 -0800
Re: cost of prolog/epilog nmm1@cam.ac.uk - 2011-11-16 18:14 +0000
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-16 16:50 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-14 17:00 -0700
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-15 10:26 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 09:41 -0700
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-15 16:40 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-15 12:44 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 09:01 -0700
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-15 15:18 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-15 21:56 -0700
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-16 09:21 +0100
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-16 09:30 +0000
Re: cost of prolog/epilog John Levine <johnl@iecc.com> - 2011-11-16 10:05 +0000
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-16 11:08 +0100
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-16 16:29 -0700
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-16 11:22 -0700
Re: cost of prolog/epilog anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-17 13:27 +0000
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-17 10:30 -0700
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-17 11:21 +0100
Re: cost of prolog/epilog Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-11-17 11:56 +0100
Re: cost of prolog/epilog timcaffrey@aol.com (Tim McCaffrey) - 2011-11-17 20:27 +0000
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-18 10:57 +0100
Re: cost of prolog/epilog BGB <cr88192@hotmail.com> - 2011-11-17 10:42 -0700
Re: cost of prolog/epilog (was: big-little) "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-11-12 14:05 -0800
Re: cost of prolog/epilog (was: big-little) Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 02:39 +0100
Re: cost of prolog/epilog torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-11-18 10:59 +0100
Re: cost of prolog/epilog Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 22:06 +0100
Re: cost of prolog/epilog (was: big-little) mac <acolvin@efunct.com> - 2011-11-20 23:01 +0000
Re: cost of prolog/epilog Chris Gray <cg@GraySage.com> - 2011-11-13 13:35 -0700
Re: big-little wclodius@lost-alamos.pet (William Clodius) - 2011-11-11 22:13 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-11 23:43 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-12 14:08 -0700
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-12 19:10 -0700
Re: big-little Chris Gray <cg@GraySage.com> - 2011-11-13 13:40 -0700
Re: big-little Bakul Shah <usenet@bitblocks.com> - 2011-11-13 14:49 -0800
Re: big-little BGB <cr88192@hotmail.com> - 2011-11-13 18:51 -0700
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-24 10:12 +0200
Re: big-little Stefan Monnier <monnier@iro.umontreal.ca> - 2011-10-24 12:11 -0400
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-24 10:28 -0700
Re: big-little nospam@ab-katrinedal.dk (Niels Jørgen Kruse) - 2011-10-24 19:38 +0200
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-24 21:02 +0200
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-23 12:02 -0700
Re: big-little Morten Reistad <first@last.name> - 2011-11-03 00:51 +0100
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-20 16:59 -0700
Re: big-little Anne & Lynn Wheeler <lynn@garlic.com> - 2011-10-20 21:13 -0400
Re: big-little nmm1@cam.ac.uk - 2011-10-21 08:01 +0100
Re: big-little "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-21 05:39 -0700
Re: big-little torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-10-24 10:18 +0200
Re: big-little Pedro Pereira <ppereira@grupopie.com> - 2011-10-21 10:40 +0100
Re: big-little Paul Gotch <paulg@at-cantab-dot.net> - 2011-10-21 12:42 +0100
Re: big-little nik Simpson <nik_s@knology.net> - 2011-10-21 11:00 -0500
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-20 21:13 +0000
Re: big-little timcaffrey@aol.com (Tim McCaffrey) - 2011-10-20 21:43 +0000
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 09:23 +0200
Re: big-little Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-21 14:35 +0200
Re: big-little Rick Jones <rick.jones2@hp.com> - 2011-10-21 17:15 +0000
Re: big-little BGB <cr88192@hotmail.com> - 2011-10-21 16:41 -0700
Re: big-little jacko <jackokring@gmail.com> - 2011-10-26 14:12 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-23 19:59 +0100 |
| Message-ID | <j81o79$5tj$1@gosset.csi.cam.ac.uk> |
| In reply to | #4346 |
In article <WH*wDrQt@news.chiark.greenend.org.uk>, Thomas Womack <twomack@chiark.greenend.org.uk> wrote: > >>But, even then, one would have to allow the application control >>over the speed of its CPUs and whether they were gang scheduled, >>or abandon a whole class of algorithms. > >You don't have to abandon them, they'll generally work correctly but >slowly. It's a problem I've got at the moment, running MPI jobs on a >NUMA machine; even if I use taskset to get it to allocate three jobs >on each of eight CPUs, the scheduler will tend to permute the jobs >around the set and leave them on a different CPU from their memory. No, I am not talking about that issue. The point about MPI is that its progress model is NOT a timing-dependent algorithm, and will work even with very erratic performance. It is designed so that neither deadlock nor livelock is possible. I am talking about the whole class of inherently timing-dependent models, such as used in the X Windowing System and TCP/IP retry. At BEST, those will work badly with the majority of combinations, but there will always be situations where they end up in livelock. I have some reason to believe that they are used in some shared memory interfaces. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-23 13:21 -0700 |
| Message-ID | <j81svp$bun$1@news.albasani.net> |
| In reply to | #4349 |
On 10/23/2011 11:59 AM, nmm1@cam.ac.uk wrote: > In article<WH*wDrQt@news.chiark.greenend.org.uk>, > Thomas Womack<twomack@chiark.greenend.org.uk> wrote: >> >>> But, even then, one would have to allow the application control >>> over the speed of its CPUs and whether they were gang scheduled, >>> or abandon a whole class of algorithms. >> >> You don't have to abandon them, they'll generally work correctly but >> slowly. It's a problem I've got at the moment, running MPI jobs on a >> NUMA machine; even if I use taskset to get it to allocate three jobs >> on each of eight CPUs, the scheduler will tend to permute the jobs >> around the set and leave them on a different CPU from their memory. > > No, I am not talking about that issue. The point about MPI is that > its progress model is NOT a timing-dependent algorithm, and will > work even with very erratic performance. It is designed so that > neither deadlock nor livelock is possible. > > I am talking about the whole class of inherently timing-dependent > models, such as used in the X Windowing System and TCP/IP retry. > At BEST, those will work badly with the majority of combinations, > but there will always be situations where they end up in livelock. > I have some reason to believe that they are used in some shared > memory interfaces. > people have much bigger problems if they are trying to handle stuff like this using busy-loops or whatever (for example, Intel explicitly discourages busy-loops, and these are no longer reliable even on the current HW). much better, and IME more common methods, are to use timers (real-time-clock, APIC timers, ...). the use of clock-based timers makes timing code independent of CPU clock rate. any other fine-grained synchronization can then be done with mutex-style locks. otherwise, one can simply assume that the timing is non-deterministic, and leave it at that (things then boil down to probabilities and stochastic systems). > > Regards, > Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-23 20:38 +0200 |
| Message-ID | <ri3en8-42g1.ln1@ntp6.tmsw.no> |
| In reply to | #4341 |
nmm1@cam.ac.uk wrote: > The reason that non-HPC applications so rarely see the problems > is that the potentially problematic event rate is massively > lower (often a factor of 10^-6 or more), so a MTBF of one day > in HPC corresponds to over a decade for non-HPC. That's your answer right there: As long as the broken/problematic hardware causes sw to crash (i.e. get stuck in a deadlock) less than once per decade, every single user will be very happy indeed, since that is longer than most systems last from first power-up until final retirement. Terje PS, I really don't mind if you can do it HPC-level stable without giving away orders of magnitude in performance. :-) A few months ago I did some experiments to come up with a better shared memory IPC mechanism (for a single producer and one to many consumers), with event rates known a priori to be on the order of one to a few per second: The testing entailed running it as fast as the cross-core memory interface would allow (~10 M events/second), and after fixing a couple of implementation bugs the worst case msg latency stayed well below 1 us. (The idea was once we've discussed previously: A power of two sized buffer with a corresponding mask, and an input index that's a full width word: All accesses use the masked index, while updates can blindly increment the counter, wraparound is ok and doesn't need any extra handling) -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-23 22:38 +0100 |
| Message-ID | <j821h1$74f$1@gosset.csi.cam.ac.uk> |
| In reply to | #4347 |
In article <ri3en8-42g1.ln1@ntp6.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > >> The reason that non-HPC applications so rarely see the problems >> is that the potentially problematic event rate is massively >> lower (often a factor of 10^-6 or more), so a MTBF of one day >> in HPC corresponds to over a decade for non-HPC. > >That's your answer right there: > >As long as the broken/problematic hardware causes sw to crash (i.e. get >stuck in a deadlock) less than once per decade, every single user will >be very happy indeed, since that is longer than most systems last from >first power-up until final retirement. Yes. Unfortunately, the increase in the use of parallelism means that has dropped a great deal, and I am fairly sure that a high proportion (10%? 90%?) of the reduction in reliability in some applications and uses that we have seen recently is due to that. This problem will only get worse, as applications move from using only very high-level, low-communication parallelism to using more low-level, higher-communication parallelism. But, as you know, no such problem is repeatable and so they very rarely get into the bug list :-( Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-23 17:56 -0700 |
| Message-ID | <j82d3u$6lt$1@news.albasani.net> |
| In reply to | #4352 |
On 10/23/2011 2:38 PM, nmm1@cam.ac.uk wrote: > In article<ri3en8-42g1.ln1@ntp6.tmsw.no>, > Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >> >>> The reason that non-HPC applications so rarely see the problems >>> is that the potentially problematic event rate is massively >>> lower (often a factor of 10^-6 or more), so a MTBF of one day >>> in HPC corresponds to over a decade for non-HPC. >> >> That's your answer right there: >> >> As long as the broken/problematic hardware causes sw to crash (i.e. get >> stuck in a deadlock) less than once per decade, every single user will >> be very happy indeed, since that is longer than most systems last from >> first power-up until final retirement. > > Yes. Unfortunately, the increase in the use of parallelism means > that has dropped a great deal, and I am fairly sure that a high > proportion (10%? 90%?) of the reduction in reliability in some > applications and uses that we have seen recently is due to that. > This problem will only get worse, as applications move from using > only very high-level, low-communication parallelism to using more > low-level, higher-communication parallelism. > > But, as you know, no such problem is repeatable and so they very > rarely get into the bug list :-( > far more likely IMO is that there will be a lot more high-level high-volume communication. this is because, sanely implemented, a mutex can be very fast (nevermind OS's like Windows supplying relatively slow built-in mutex objects, and the "critical section" objects are still a bit slow, forcing people to implement their own). if mutexes are relatively fast, and critical sections fairly short, IME waiting on mutexes is fairly rare. hence, it makes the most sense to make the lock/unlock very fast in the case where there is no collision. hence, one can implement a mutex which looks like a short spinlock followed by a sleep loop. granted, this does not-pretty things if one wants to (intentionally) have multiple threads waiting on a given mutex (at which point the OS-provided mutexes are better). on Linux is is not such a big issue though, as pthreads seems to provide reasonably fast mutexes by default. then people can have message queues, and lots of them... one can build a message queue like: lock queue; add or remove message; unlock queue. at least for my uses, message queues have generally been plenty fast enough. however, none of this requires strict reliance on either determinism or specific CPU clock-rate behavior. granted: in particularly nasty conditions (say, likely poorly designed apps, where much time goes into threads fighting over a mutex) then the slower core may be more likely to have a lower chance of getting the lock (since it will only try to lock 1/2 or 1/4 as often as the faster cores). granted, I have discovered a few race-condition style bugs in my projects: there is currently a condition where it seems that "gcrealloc()" calls (like plain "realloc()", but for my garbage collector) can get into the GC without locking things properly, which can in certain cases result in crashes (I suspect due to different parts of the GC trampling on each other). sadly, this GC wasn't originally designed to be multi-threaded (or a concurrent GC), but I just sort of kludged it into this use later (and have been gradually making it less terrible). I before noted that apparently it is possible to deadlock MSVCRT as well. I once had one of my apps deadlock, and observed in the debugger that several threads were in different functions: malloc(); realloc(); free(); "_msize();" as, somewhere along, all had deadlocked each other. however, I don't think any of this is any particular reason to not have multiple clock-rate cores. likewise, parallelism is inherently non-deterministic anyways.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-24 07:58 +0100 |
| Message-ID | <j832aa$og0$1@gosset.csi.cam.ac.uk> |
| In reply to | #4355 |
In article <j82d3u$6lt$1@news.albasani.net>, BGB <cr88192@hotmail.com> wrote: >>> >>>> The reason that non-HPC applications so rarely see the problems >>>> is that the potentially problematic event rate is massively >>>> lower (often a factor of 10^-6 or more), so a MTBF of one day >>>> in HPC corresponds to over a decade for non-HPC. >>> >>> That's your answer right there: >>> >>> As long as the broken/problematic hardware causes sw to crash (i.e. get >>> stuck in a deadlock) less than once per decade, every single user will >>> be very happy indeed, since that is longer than most systems last from >>> first power-up until final retirement. >> >> Yes. Unfortunately, the increase in the use of parallelism means >> that has dropped a great deal, and I am fairly sure that a high >> proportion (10%? 90%?) of the reduction in reliability in some >> applications and uses that we have seen recently is due to that. >> This problem will only get worse, as applications move from using >> only very high-level, low-communication parallelism to using more >> low-level, higher-communication parallelism. >> >> But, as you know, no such problem is repeatable and so they very >> rarely get into the bug list :-( > >far more likely IMO is that there will be a lot more high-level >high-volume communication. > >this is because, sanely implemented, a mutex can be very fast (nevermind >OS's like Windows supplying relatively slow built-in mutex objects, and >the "critical section" objects are still a bit slow, forcing people to >implement their own). > >if mutexes are relatively fast, and critical sections fairly short, IME >waiting on mutexes is fairly rare. hence, it makes the most sense to >make the lock/unlock very fast in the case where there is no collision. Sigh. One of the hardest things to teach about parallelism, and software engineering generally, is that solving the bottom-level problems does not help significantly with the structural ones. The problems that I am referring to are inherent in the logic (the new and trendy word is 'emergent'), and are there even if you have universal atomicity AND sequential consistency AND infinitely fast locking and unlocking primitives. The analogy that I use is that the effect of adding parallelism to time is like moving from Newtonian mechanics to special relativity. Whole classes of synchronisation methods become invalid, though they continue to work under most circumstances because the relative velocities are so low. It's exactly the same here. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-24 16:34 -0700 |
| Message-ID | <j84sm2$g94$1@news.albasani.net> |
| In reply to | #4357 |
On 10/23/2011 11:58 PM, nmm1@cam.ac.uk wrote: > In article<j82d3u$6lt$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >>>> >>>>> The reason that non-HPC applications so rarely see the problems >>>>> is that the potentially problematic event rate is massively >>>>> lower (often a factor of 10^-6 or more), so a MTBF of one day >>>>> in HPC corresponds to over a decade for non-HPC. >>>> >>>> That's your answer right there: >>>> >>>> As long as the broken/problematic hardware causes sw to crash (i.e. get >>>> stuck in a deadlock) less than once per decade, every single user will >>>> be very happy indeed, since that is longer than most systems last from >>>> first power-up until final retirement. >>> >>> Yes. Unfortunately, the increase in the use of parallelism means >>> that has dropped a great deal, and I am fairly sure that a high >>> proportion (10%? 90%?) of the reduction in reliability in some >>> applications and uses that we have seen recently is due to that. >>> This problem will only get worse, as applications move from using >>> only very high-level, low-communication parallelism to using more >>> low-level, higher-communication parallelism. >>> >>> But, as you know, no such problem is repeatable and so they very >>> rarely get into the bug list :-( >> >> far more likely IMO is that there will be a lot more high-level >> high-volume communication. >> >> this is because, sanely implemented, a mutex can be very fast (nevermind >> OS's like Windows supplying relatively slow built-in mutex objects, and >> the "critical section" objects are still a bit slow, forcing people to >> implement their own). >> >> if mutexes are relatively fast, and critical sections fairly short, IME >> waiting on mutexes is fairly rare. hence, it makes the most sense to >> make the lock/unlock very fast in the case where there is no collision. > > Sigh. One of the hardest things to teach about parallelism, and > software engineering generally, is that solving the bottom-level > problems does not help significantly with the structural ones. > > The problems that I am referring to are inherent in the logic (the > new and trendy word is 'emergent'), and are there even if you have > universal atomicity AND sequential consistency AND infinitely fast > locking and unlocking primitives. > > The analogy that I use is that the effect of adding parallelism > to time is like moving from Newtonian mechanics to special > relativity. Whole classes of synchronisation methods become > invalid, though they continue to work under most circumstances > because the relative velocities are so low. It's exactly the > same here. > I don't think mismatched clock rates will break either the operation of mutexes, of critical sections in general, or of things like message queues. much above the level of message queues, the speed of the cores, and even whether execution is sequential or parallel, largely cease to matter (and if they do matter for a given piece of software, this can rightly be considered a bug, and is subject to the expectation that someone go fix it). this is largely about like going and complaining that "rdtsc" is broken because it will give different values and jump forwards/backwards, ... as a thread gets rescheduled from one core to another, or because if one calls rdtsc in a loop, there is some level of "noise" in the returned values (presumably due to whatever else is going on in the system). or such...
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-25 08:09 +0100 |
| Message-ID | <j85nar$56r$1@gosset.csi.cam.ac.uk> |
| In reply to | #4369 |
In article <j84sm2$g94$1@news.albasani.net>, BGB <cr88192@hotmail.com> wrote: > >I don't think mismatched clock rates will break either the operation of >mutexes, of critical sections in general, or of things like message queues. That is true. >much above the level of message queues, the speed of the cores, and even >whether execution is sequential or parallel, largely cease to matter >(and if they do matter for a given piece of software, this can rightly >be considered a bug, and is subject to the expectation that someone go >fix it). A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring. That is exactly like saying that, if all memory actions are atomic, any problems with memory consistency are simple bugs. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-25 14:52 +0200 |
| Message-ID | <02oin8-qg03.ln1@ntp6.tmsw.no> |
| In reply to | #4373 |
nmm1@cam.ac.uk wrote: > In article<j84sm2$g94$1@news.albasani.net>, BGB<cr88192@hotmail.com> wrote: >> much above the level of message queues, the speed of the cores, and even >> whether execution is sequential or parallel, largely cease to matter >> (and if they do matter for a given piece of software, this can rightly >> be considered a bug, and is subject to the expectation that someone go >> fix it). > > A little learning is a dang'rous thing; > Drink deep, or taste not the Pierian spring. > > That is exactly like saying that, if all memory actions are atomic, > any problems with memory consistency are simple bugs. Yes...and in some ways that would even be true...as long as you never had an object larger than a single memory word... :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-25 17:28 +0100 |
| Message-ID | <j86o2i$83b$1@gosset.csi.cam.ac.uk> |
| In reply to | #4376 |
In article <02oin8-qg03.ln1@ntp6.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > >>> much above the level of message queues, the speed of the cores, and even >>> whether execution is sequential or parallel, largely cease to matter >>> (and if they do matter for a given piece of software, this can rightly >>> be considered a bug, and is subject to the expectation that someone go >>> fix it). >> >> A little learning is a dang'rous thing; >> Drink deep, or taste not the Pierian spring. >> >> That is exactly like saying that, if all memory actions are atomic, >> any problems with memory consistency are simple bugs. > >Yes...and in some ways that would even be true...as long as you never >had an object larger than a single memory word... >:-) Sorry, Terje, not even then! You may be assuming sequential consistency, but that is not guaranteed by mere atomicity. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-25 13:06 -0700 |
| Message-ID | <j874qg$edl$1@news.albasani.net> |
| In reply to | #4379 |
On 10/25/2011 9:28 AM, nmm1@cam.ac.uk wrote: > In article<02oin8-qg03.ln1@ntp6.tmsw.no>, > Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >> >>>> much above the level of message queues, the speed of the cores, and even >>>> whether execution is sequential or parallel, largely cease to matter >>>> (and if they do matter for a given piece of software, this can rightly >>>> be considered a bug, and is subject to the expectation that someone go >>>> fix it). >>> >>> A little learning is a dang'rous thing; >>> Drink deep, or taste not the Pierian spring. >>> >>> That is exactly like saying that, if all memory actions are atomic, >>> any problems with memory consistency are simple bugs. >> >> Yes...and in some ways that would even be true...as long as you never >> had an object larger than a single memory word... >> :-) > > Sorry, Terje, not even then! You may be assuming sequential > consistency, but that is not guaranteed by mere atomicity. > the main problem though is if people do things which are inherently safe, namely accessing data shared between threads without using locks. in the usual case though, each thread "owns" whatever data it works with, and any communication between threads is via message passing. any other operations thus require being performed under the control of mutexes and similar (IOW: "critical sections"). any case where access to data is shared, but not properly protected, can be considered itself a potential bug. basically, this is analogous to the strategy used by Erlang, except generally done using C or C++, and less strict. IRL though, it often means that a lot of shared subsystems though end up having to be protected via mutexes, for example, the memory manager and garbage collector, since this is shared between multiple threads. many other systems may require locking as well, such as often operations involving objects, ... for example, a VM may "lock" the entire object-system during any operations for which it needs to add or update the classes (say, a new class was added by some newly compiled code, or an existing class has been modified), ... this often means locking/unlocking for some misc operations, such as looking/fetching up fields or methods (with a few edge cases to avoid locking for "safe" operations). but, in practice, everything seems to work fairly well for the most part, so no real issue... if a person really insists on strict determinism and so on, then they can probably just write only single-threaded code (nevermind if the OS may run some of its own threads in a given process as well, like Windows which seems to usually just leave several "helper threads" even for otherwise single-threaded apps, or at least as far as I have seen). nevermind that strict determinism is almost an unreachable goal under an OS like Windows anyways, so may as well just assume that the OS's behavior/timings/... is not strictly deterministic, and leave it at that. but, anyways, the point is that variable clock-rates will not likely make matters much worse than they are already. or such...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-10-25 15:22 -0700 |
| Message-ID | <j87cq2$urd$1@news.albasani.net> |
| In reply to | #4380 |
On 10/25/2011 1:06 PM, BGB wrote: > On 10/25/2011 9:28 AM, nmm1@cam.ac.uk wrote: >> In article<02oin8-qg03.ln1@ntp6.tmsw.no>, >> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >>> >>>>> much above the level of message queues, the speed of the cores, and >>>>> even >>>>> whether execution is sequential or parallel, largely cease to matter >>>>> (and if they do matter for a given piece of software, this can rightly >>>>> be considered a bug, and is subject to the expectation that someone go >>>>> fix it). >>>> >>>> A little learning is a dang'rous thing; >>>> Drink deep, or taste not the Pierian spring. >>>> >>>> That is exactly like saying that, if all memory actions are atomic, >>>> any problems with memory consistency are simple bugs. >>> >>> Yes...and in some ways that would even be true...as long as you never >>> had an object larger than a single memory word... >>> :-) >> >> Sorry, Terje, not even then! You may be assuming sequential >> consistency, but that is not guaranteed by mere atomicity. >> > > the main problem though is if people do things which are inherently > safe, namely accessing data shared between threads without using locks. > ^ inherently unsafe... another subtle issue though is that many C compilers are optimized for single-threaded code, and so will cache variables in registers. if multiple threads may modify the variable, then this may also be unsafe. a partial fix is using "volatile", where the compiler will always read/write the variable directly, rather than use a register as a proxy. however, this doesn't guarantee consistency between CPUs (apart from using the "lock" prefix or similar, for which AFAIK there is no standard/common C-land mechamism). a simpler strategy though is not to assume strict consistency with shared data, and instead mostly shun data sharing, and instead use message-passing and ownership-transfer as strategies (if only ever a single thread owns a piece of data, then keeping it consistent is much easier). likewise, dividing up threads by code-region, ... so that unrelated threads will not normally be working on the same data at the same time (except where unavoidable, generally in areas related to the language/VM run-times or similar). other things may be related to language-design, for example, incorporating some ideas similar to those in the "Java memory model", ... or such...
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-10-25 19:47 -0700 |
| Message-ID | <4EA774C4.4040505@SPAM.comp-arch.net> |
| In reply to | #4379 |
On 10/25/2011 9:28 AM, nmm1@cam.ac.uk wrote: > In article<02oin8-qg03.ln1@ntp6.tmsw.no>, > Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >> >>>> much above the level of message queues, the speed of the cores, and even >>>> whether execution is sequential or parallel, largely cease to matter >>>> (and if they do matter for a given piece of software, this can rightly >>>> be considered a bug, and is subject to the expectation that someone go >>>> fix it). >>> >>> A little learning is a dang'rous thing; >>> Drink deep, or taste not the Pierian spring. >>> >>> That is exactly like saying that, if all memory actions are atomic, >>> any problems with memory consistency are simple bugs. >> >> Yes...and in some ways that would even be true...as long as you never >> had an object larger than a single memory word... >> :-) > > Sorry, Terje, not even then! You may be assuming sequential > consistency, but that is not guaranteed by mere atomicity. Terminology check: many software people, especially Microsoft people my experience, say "atomic" when they mean "sequential consistency". Their reasoning is "The operation appears to occur once and only once, everywhere in the system, at the same time. If that isn;t atomic, what is?"
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-26 08:09 +0100 |
| Message-ID | <j88bnb$c24$1@gosset.csi.cam.ac.uk> |
| In reply to | #4387 |
In article <4EA774C4.4040505@SPAM.comp-arch.net>, Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote: > >Terminology check: many software people, especially Microsoft people my >experience, say "atomic" when they mean "sequential consistency". Yes. I have no truck with that appalling example of dumbed-down revisionism. It's as bad as the frightful abuse of terminology in 'computer science' "non-deterministic automaton", for heaven's sake! I don't think that Terje made that mistake, anyway. >Their reasoning is "The operation appears to occur once and only once, >everywhere in the system, at the same time. If that isn;t atomic, what is?" Yes - but, as you, Terje, I and most of the others with Clue know, even that shows an inherent misunderstanding! That's stronger even than the combination of atomicity and sequential consistency, though I am not sure that you can distinguish it from that without also adding a clock (either physical time or global) to the ISA. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-26 12:06 +0200 |
| Message-ID | <6n2ln8-iv1.ln1@ntp6.tmsw.no> |
| In reply to | #4390 |
nmm1@cam.ac.uk wrote: > In article<4EA774C4.4040505@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net> wrote: >> >> Terminology check: many software people, especially Microsoft people my >> experience, say "atomic" when they mean "sequential consistency". > > Yes. I have no truck with that appalling example of dumbed-down > revisionism. It's as bad as the frightful abuse of terminology > in 'computer science' "non-deterministic automaton", for heaven's > sake! I don't think that Terje made that mistake, anyway. > >> Their reasoning is "The operation appears to occur once and only once, >> everywhere in the system, at the same time. If that isn;t atomic, what is?" > > Yes - but, as you, Terje, I and most of the others with Clue know, > even that shows an inherent misunderstanding! > > That's stronger even than the combination of atomicity and sequential > consistency, though I am not sure that you can distinguish it from > that without also adding a clock (either physical time or global) > to the ISA. I know I wasn't very clear, but once again, please re-read what I wrote: I intended this to be for a system with zero relationships between individual objects, both the previous and the new value would be valid, and timing does not matter at all. At that point the only critical issue is that you must be able to update an entire word at once, so that nobody can ever retrieve a partially updated word/record/object. I.e. basically a mostly useless system. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-26 10:47 +0100 |
| Message-ID | <j88kur$dvv$1@gosset.csi.cam.ac.uk> |
| In reply to | #4392 |
In article <6n2ln8-iv1.ln1@ntp6.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > >I know I wasn't very clear, but once again, please re-read what I wrote: > >I intended this to be for a system with zero relationships between >individual objects, both the previous and the new value would be valid, >and timing does not matter at all. > >At that point the only critical issue is that you must be able to update >an entire word at once, so that nobody can ever retrieve a partially >updated word/record/object. > >I.e. basically a mostly useless system. Ah. I misunderstood, then. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-10-26 11:58 +0200 |
| Message-ID | <072ln8-su1.ln1@ntp6.tmsw.no> |
| In reply to | #4387 |
Andy "Krazy" Glew wrote: > On 10/25/2011 9:28 AM, nmm1@cam.ac.uk wrote: >> In article<02oin8-qg03.ln1@ntp6.tmsw.no>, >> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote: >>> Yes...and in some ways that would even be true...as long as you never >>> had an object larger than a single memory word... >>> :-) >> >> Sorry, Terje, not even then! You may be assuming sequential >> consistency, but that is not guaranteed by mere atomicity. > > Terminology check: many software people, especially Microsoft people my > experience, say "atomic" when they mean "sequential consistency". > > Their reasoning is "The operation appears to occur once and only once, > everywhere in the system, at the same time. If that isn;t atomic, what is?" > Except for the "at the same time" part, this is exactly what I meant: Every process observing/using/updating any item will either get the previous value, or the updated value, and never something that's half-way updated. You can still cache things in registers and use it after another system as updated it, this is effectively the same as a late-arriving update. However, since I also specified that there were "no object larger than a single word", that would disallow any cross-object dependencies. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-26 10:44 +0100 |
| Message-ID | <j88kqj$duk$1@gosset.csi.cam.ac.uk> |
| In reply to | #4391 |
In article <072ln8-su1.ln1@ntp6.tmsw.no>,
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>Andy "Krazy" Glew wrote:
>
>>>> Yes...and in some ways that would even be true...as long as you never
>>>> had an object larger than a single memory word...
>>>> :-)
>>>
>>> Sorry, Terje, not even then! You may be assuming sequential
>>> consistency, but that is not guaranteed by mere atomicity.
>>
>> Terminology check: many software people, especially Microsoft people my
>> experience, say "atomic" when they mean "sequential consistency".
>>
>> Their reasoning is "The operation appears to occur once and only once,
>> everywhere in the system, at the same time. If that isn;t atomic, what is?"
>>
>Except for the "at the same time" part, this is exactly what I meant:
>
>Every process observing/using/updating any item will either get the
>previous value, or the updated value, and never something that's
>half-way updated.
Yes, but that's not enough! Dekker's algorithm and others can fail
even if that is true. Consider this example:
Thread 1 Thread 2
Synchronise
A = 1 B = 1
Print B Print A
On Intel and AMD systems, you can and do have both print statements
print zero. The writes are atomic but not sequentially consistent.
See Litmus in:
http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html
Regards,
Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 03:45 -0700 |
| Message-ID | <545278b3-7435-4dd4-b370-dfbdb57330d3@s14g2000vbj.googlegroups.com> |
| In reply to | #4393 |
On Oct 26, 11:44 am, n...@cam.ac.uk wrote:
> In article <072ln8-su1....@ntp6.tmsw.no>,
> Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>
>
>
> >Andy "Krazy" Glew wrote:
>
> >>>> Yes...and in some ways that would even be true...as long as you never
> >>>> had an object larger than a single memory word...
> >>>> :-)
>
> >>> Sorry, Terje, not even then! You may be assuming sequential
> >>> consistency, but that is not guaranteed by mere atomicity.
>
> >> Terminology check: many software people, especially Microsoft people my
> >> experience, say "atomic" when they mean "sequential consistency".
>
> >> Their reasoning is "The operation appears to occur once and only once,
> >> everywhere in the system, at the same time. If that isn;t atomic, what is?"
>
> >Except for the "at the same time" part, this is exactly what I meant:
>
> >Every process observing/using/updating any item will either get the
> >previous value, or the updated value, and never something that's
> >half-way updated.
>
> Yes, but that's not enough! Dekker's algorithm and others can fail
> even if that is true. Consider this example:
>
> Thread 1 Thread 2
> Synchronise
> A = 1 B = 1
> Print B Print A
>
> On Intel and AMD systems, you can and do have both print statements
> print zero. The writes are atomic but not sequentially consistent.
> See Litmus in:
>
> http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html
>
> Regards,
> Nick Maclaren.
But your original statement starts with "if all memory actions are
atomic". IIRC, on Intel/AMD there is no such thing as atomic
individual store. All atomic primitives should consist of load and
store to the same location.
Let's modify your example:
Thread 1 Thread 2
A=0 B=0
Synchronise
lock inc A lock inc B
Print B Print A
Now at least one of the threads will always print 1.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-26 11:45 +0100 |
| Message-ID | <j88ocm$epo$1@gosset.csi.cam.ac.uk> |
| In reply to | #4395 |
In article <545278b3-7435-4dd4-b370-dfbdb57330d3@s14g2000vbj.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: > >But your original statement starts with "if all memory actions are >atomic". IIRC, on Intel/AMD there is no such thing as atomic >individual store. You don't. Look it up. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.arch
csiph-web