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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 09:15 -0700 |
| Message-ID | <b9f48152-d476-4ba5-83c4-496e27a8f206@k10g2000yqn.googlegroups.com> |
| In reply to | #4396 |
On Oct 26, 12:45 pm, n...@cam.ac.uk wrote: > In article <545278b3-7435-4dd4-b370-dfbdb5733...@s14g2000vbj.googlegroups.com>, > Michael S <already5cho...@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. You are correct. I intermixed "atomic" with "locked atomic" in my mind.
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-10-26 12:51 -0700 |
| Message-ID | <4EA864B6.4000602@SPAM.comp-arch.net> |
| In reply to | #4395 |
On 10/26/2011 3:45 AM, Michael S wrote: > 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. >>... > 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. Terminology conflict flagged. In Intel and AMD parlance aligned stores are atomic. They are either seen to be done, or not done. Never half way done. But, they may not be seen to be done by all people at the same time, or even virtual notion of time. -- By the way: there have been systems where RMW (atomic load/stores) may also not be ordered. IIRC Itanium.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Reilly <areilly---@bigpond.net.au> |
|---|---|
| Date | 2011-10-26 11:45 +0000 |
| Message-ID | <9gqa79FkhcU1@mid.individual.net> |
| In reply to | #4393 |
On Wed, 26 Oct 2011 10:44:51 +0100, nmm1 wrote: > In article <072ln8-su1.ln1@ntp6.tmsw.no>, > Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >>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! Not enough for what? I admit to not being particularly down with the modern computer science, but I've done some multi-processor code. That sounds like about as much consistency as one could hope for, in general. > 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. Sure they are. Imagine that thread 1 and thread 2 are far away from each other. Why should either see modifications that originate at the other before they go on and do something else? Each thread is perfectly consistent with it's own view of the world, which is all that it has. > See Litmus in: > > http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html Thanks for that link. I haven't read it (and the linked pages) yet, but it looks quite comprehensive. I'm just posting because I'm curious. What real algorithms and applications care or break as a result of the situation you described in your example? Cheers, -- Andrew
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-26 15:42 +0100 |
| Message-ID | <j8969e$ge1$1@gosset.csi.cam.ac.uk> |
| In reply to | #4397 |
In article <9gqa79FkhcU1@mid.individual.net>, Andrew Reilly <areilly---@bigpond.net.au> wrote: > >> 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. > >Sure they are. Imagine that thread 1 and thread 2 are far away from each >other. Why should either see modifications that originate at the other >before they go on and do something else? Each thread is perfectly >consistent with it's own view of the world, which is all that it has. Er, try a Web search for "sequential consistency" and look at the first hit. Then do the same for Dekker's algorithm. If you can find it, Lamport's original paper defining sequential consistency is quite readable. >> See Litmus in: >> >> http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html > >Thanks for that link. I haven't read it (and the linked pages) yet, but >it looks quite comprehensive. It is. I don't advise you to use it as a basis until you have found out rather more about the problem. >I'm just posting because I'm curious. What real algorithms and >applications care or break as a result of the situation you described in >your example? Lots! A lot of widely-used synchronisation methods rely on that property, for a start. Even if you use only provided mutexes, the same problem applies in theory to when you use a separate mutexes for each variable (as is needed for efficiency in most large programs). I have also seen 'obviously' correct application code fail because it assumed sequential consistency. That was another consistency issue, which is even worse to resolve on highly-parallel systems. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 09:07 -0700 |
| Message-ID | <715712dc-098c-4e97-8799-132022ea3f8a@j20g2000vby.googlegroups.com> |
| In reply to | #4399 |
On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: > > Er, try a Web search for "sequential consistency" and look at the > first hit. Nice definition, but absolutely impractical as main memory sequencing model. It looks impossible to implement in efficient manner on CMP/SMP with distributed caches and/or on any sorts of NUMA, even the cacheless ones. Now as an auxiliary special-purpose model for synchronization primitives it is both practical (except for really big SMP) and easy to implement. In case of Intel/AMD normal (i.e. write-back) memory regions in order to get here you just have to limit yourself to naturally-aligned data units and replace all store instructions by "lock xchg".
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-10-26 12:53 -0700 |
| Message-ID | <4EA8653F.30303@SPAM.comp-arch.net> |
| In reply to | #4401 |
On 10/26/2011 9:07 AM, Michael S wrote: > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: >> >> Er, try a Web search for "sequential consistency" and look at the >> first hit. > > Nice definition, but absolutely impractical as main memory sequencing > model. It looks impossible to implement in efficient manner on CMP/SMP > with distributed caches and/or on any sorts of NUMA, even the > cacheless ones. Interesting. It's the memory model for IBM mainframes.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-26 21:05 +0100 |
| Message-ID | <j89p6t$ipt$1@gosset.csi.cam.ac.uk> |
| In reply to | #4408 |
In article <4EA8653F.30303@SPAM.comp-arch.net>, Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote: >On 10/26/2011 9:07 AM, Michael S wrote: >> On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: >>> >>> Er, try a Web search for "sequential consistency" and look at the >>> first hit. >> >> Nice definition, but absolutely impractical as main memory sequencing >> model. It looks impossible to implement in efficient manner on CMP/SMP >> with distributed caches and/or on any sorts of NUMA, even the >> cacheless ones. > >Interesting. > >It's the memory model for IBM mainframes. It's also apparently assumed by Microsoft, and is required by the new C++ standard. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 13:20 -0700 |
| Message-ID | <94b03de6-6c0b-489a-84d0-4f6849d004d0@f36g2000vbm.googlegroups.com> |
| In reply to | #4409 |
On Oct 26, 10:05 pm, n...@cam.ac.uk wrote: > In article <4EA8653F.30...@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew <a...@SPAM.comp-arch.net> wrote: > > >On 10/26/2011 9:07 AM, Michael S wrote: > >> On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: > > >>> Er, try a Web search for "sequential consistency" and look at the > >>> first hit. > > >> Nice definition, but absolutely impractical as main memory sequencing > >> model. It looks impossible to implement in efficient manner on CMP/SMP > >> with distributed caches and/or on any sorts of NUMA, even the > >> cacheless ones. > > >Interesting. > > >It's the memory model for IBM mainframes. > > It's also apparently assumed by Microsoft, Where? > and is required by the new C++ standard. Well, you surely know more than most of us about language standards, but if it's true it will draw the standard useless. Also it would be a big departure from the previous standard, that simply says (IMHO, wisely) something like - multiprocessing is out of our scope. > > Regards, > Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2011-10-26 17:55 -0700 |
| Message-ID | <4EA8AC08.3030009@SPAM.comp-arch.net> |
| In reply to | #4409 |
On 10/26/2011 1:05 PM, nmm1@cam.ac.uk wrote: > In article<4EA8653F.30303@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net> wrote: >> On 10/26/2011 9:07 AM, Michael S wrote: >>> On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: >>>> >>>> Er, try a Web search for "sequential consistency" and look at the >>>> first hit. >>> >>> Nice definition, but absolutely impractical as main memory sequencing >>> model. It looks impossible to implement in efficient manner on CMP/SMP >>> with distributed caches and/or on any sorts of NUMA, even the >>> cacheless ones. >> >> Interesting. >> >> It's the memory model for IBM mainframes. > > It's also apparently assumed by Microsoft, and is required by the > new C++ standard. Not true.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-27 09:10 +0100 |
| Message-ID | <j8b3l3$npd$1@gosset.csi.cam.ac.uk> |
| In reply to | #4423 |
In article <4EA8AC08.3030009@SPAM.comp-arch.net>, Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote: >>>>> >>>>> Er, try a Web search for "sequential consistency" and look at the >>>>> first hit. >>>> >>>> Nice definition, but absolutely impractical as main memory sequencing >>>> model. It looks impossible to implement in efficient manner on CMP/SMP >>>> with distributed caches and/or on any sorts of NUMA, even the >>>> cacheless ones. >>> >>> Interesting. >>> >>> It's the memory model for IBM mainframes. >> >> It's also apparently assumed by Microsoft, and is required by the >> new C++ standard. > >Not true. Er, which is not true, and what is your evidence for saying that? The first was hearsay, from a usually reliable source, on WG21; that is why I said "apparently". If you want to challenge me on the latter, please feel free :-) I was somewhat involved, though not a major player. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-27 01:34 -0700 |
| Message-ID | <e65f8556-7eed-4754-bb9c-b021bb98b3a3@y36g2000yqm.googlegroups.com> |
| In reply to | #4429 |
On Oct 27, 10:10 am, n...@cam.ac.uk wrote: > In article <4EA8AC08.3030...@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew <a...@SPAM.comp-arch.net> wrote: > > > > > > >>>>> Er, try a Web search for "sequential consistency" and look at the > >>>>> first hit. > > >>>> Nice definition, but absolutely impractical as main memory sequencing > >>>> model. It looks impossible to implement in efficient manner on CMP/SMP > >>>> with distributed caches and/or on any sorts of NUMA, even the > >>>> cacheless ones. > > >>> Interesting. > > >>> It's the memory model for IBM mainframes. > > >> It's also apparently assumed by Microsoft, and is required by the > >> new C++ standard. > > >Not true. > > Er, which is not true, and what is your evidence for saying that? > The first was hearsay, from a usually reliable source, on WG21; > that is why I said "apparently". So your "usually reliable source" is "apparently" wrong in this particular case. It's a fact that WinNT during 18 years of his history worked on 5 different architectures (and the 6th is coming really soon) all of which offered cache-coherent SMP, but none of which guaranteed "sequential consistency.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-27 10:29 +0100 |
| Message-ID | <j8b8a9$pim$1@gosset.csi.cam.ac.uk> |
| In reply to | #4430 |
In article <e65f8556-7eed-4754-bb9c-b021bb98b3a3@y36g2000yqm.googlegroups.com>, Michael S <already5chosen@yahoo.com> wrote: > >So your "usually reliable source" is "apparently" wrong in this >particular case. So far, I have seen no evidence to the contrary - you have changed the context and are irrelevant. >It's a fact that WinNT during 18 years of his history worked on 5 >different architectures (and the 6th is coming really soon) all of >which offered cache-coherent SMP, but none of which guaranteed >"sequential consistency. I have managed a POSIX-compatible Unix, and know of others, that used genuinely distributed memory but yet ran a single system image. However, that does NOT mean that POSIX threads do not require shared memory, nor that all Unices can run on distributed memory. The fact that Microsoft does not require it under some circumstances does not imply that it does not require it under any circumstances. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-27 04:28 -0700 |
| Message-ID | <200fd312-9cf1-4dea-b7ac-273183c5bd3c@s7g2000yqa.googlegroups.com> |
| In reply to | #4433 |
On Oct 27, 11:29 am, n...@cam.ac.uk wrote: > In article <e65f8556-7eed-4754-bb9c-b021bb98b...@y36g2000yqm.googlegroups.com>, > Michael S <already5cho...@yahoo.com> wrote: > > >So your "usually reliable source" is "apparently" wrong in this > >particular case. > > So far, I have seen no evidence to the contrary - you have changed > the context and are irrelevant. > Are you trying to say that "assumed by Microsoft" is not equivalent to and wider than "required for correct operation of Microsoft Windows NT family of operation systems"? I.e. NT itself does not rely on sequential consistency but some of the major MS apps do? Even in that form I find it extremely improbable. What I do believe is true is that some major Microsoft and 3rd party Windows applications (but not MS SQLServer) rely on "Interlocked" family of primitives and on xxxCriticalSection library calls to imply the global memory fence. Which is guaranteed on x86 but not guaranteed on few other former and current Windows target ISAs. But that's not quite the same as assuming sequential consistency for all memory operations.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2011-10-27 12:22 -0400 |
| Message-ID | <2Afqq.1545$zi2.44@newsfe10.iad> |
| In reply to | #4436 |
Michael S wrote: > > What I do believe is true is that some major Microsoft and 3rd party > Windows applications (but not MS SQLServer) rely on "Interlocked" > family of primitives and on xxxCriticalSection library calls to imply > the global memory fence. Which is guaranteed on x86 but not guaranteed > on few other former and current Windows target ISAs. But that's not > quite the same as assuming sequential consistency for all memory > operations. MS InterlockedXxx functions have a full memory barrier. They have separate InterlockedXxxAcquire and InterlockedXxxRelease functions but those are only supported on Itanium. The documentation on critical sections says nothing about barriers though they are assumed to be full or many things would break. The MS C/C++ compiler has intrinsics _ReadBarrier, _WriteBarrier, _ReadWriteBarrier but these only prevent compiler optimization reordering and not memory consistency. (The older documentation did *not* say that these only affected optimization so there very well could be code floating about that thinks they FENCE.) There is a MemoryBarrier macro that "Creates a hardware memory barrier (fence) that prevents the CPU from re-ordering read and write operations. It may also prevent the compiler from re-ordering read and write operations." Eric
[toc] | [prev] | [next] | [standalone]
| From | timcaffrey@aol.com (Tim McCaffrey) |
|---|---|
| Date | 2011-10-27 18:08 +0000 |
| Message-ID | <j8c6nq$3o3$1@USTR-NEWS.TR.UNISYS.COM> |
| In reply to | #4430 |
In article <e65f8556-7eed-4754-bb9c-b021bb98b3a3@y36g2000yqm.googlegroups.com>, already5chosen@yahoo.com says... > >So your "usually reliable source" is "apparently" wrong in this >particular case. >It's a fact that WinNT during 18 years of his history worked on 5 >different architectures (and the 6th is coming really soon) all of >which offered cache-coherent SMP, but none of which guaranteed >"sequential consistency. If your talking about ARM, cache-coherent SMP is not a given. Many ARM implementations in the past did not have it (I'm not up on what is current). And, yes, it is a pain to program around (especially at the device driver level). - Tim
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-27 11:50 -0700 |
| Message-ID | <1968f63c-14d0-4c41-a67a-e1b32961a786@x21g2000yqb.googlegroups.com> |
| In reply to | #4446 |
On Oct 27, 8:08 pm, timcaff...@aol.com (Tim McCaffrey) wrote: > In article > <e65f8556-7eed-4754-bb9c-b021bb98b...@y36g2000yqm.googlegroups.com>, > already5cho...@yahoo.com says... > > > > >So your "usually reliable source" is "apparently" wrong in this > >particular case. > >It's a fact that WinNT during 18 years of his history worked on 5 > >different architectures (and the 6th is coming really soon) all of > >which offered cache-coherent SMP, but none of which guaranteed > >"sequential consistency. > > If your talking about ARM, cache-coherent SMP is not a given. Many ARM > implementations in the past did not have it (I'm not up on what is current). > And, yes, it is a pain to program around (especially at the device driver > level). > > - Tim I'd expect that Cortex-A profile of ARM v.7 ISA that among other things has clear definition for cache coherence and for memory ordering model in SMP environment will be a minimal requirement for "big" Win8. Windows 8 Phone is a different story. Here they will likely continue to support XScale which is a variant of ARM v.5 ISA.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2011-10-27 14:10 +0200 |
| Message-ID | <87aa8m3a9r.fsf@news.bourguet.org> |
| In reply to | #4429 |
nmm1@cam.ac.uk writes: > In article <4EA8AC08.3030009@SPAM.comp-arch.net>, > Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote: >>>>>> >>>>>> Er, try a Web search for "sequential consistency" and look at the >>>>>> first hit. >>>>> >>>>> Nice definition, but absolutely impractical as main memory sequencing >>>>> model. It looks impossible to implement in efficient manner on CMP/SMP >>>>> with distributed caches and/or on any sorts of NUMA, even the >>>>> cacheless ones. >>>> >>>> Interesting. >>>> >>>> It's the memory model for IBM mainframes. >>> >>> It's also apparently assumed by Microsoft, and is required by the >>> new C++ standard. >> >>Not true. > > Er, which is not true, and what is your evidence for saying that? > The first was hearsay, from a usually reliable source, on WG21; > that is why I said "apparently". If you want to challenge me on > the latter, please feel free :-) I was somewhat involved, though > not a major player. Either you or I misunderstand something. The section "1.10 Multi-threaded executions and data races" seems to me to define a model more relaxed than sequential consistency. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-10-27 17:58 +0100 |
| Message-ID | <j8c2kb$vck$1@gosset.csi.cam.ac.uk> |
| In reply to | #4438 |
In article <87aa8m3a9r.fsf@news.bourguet.org>, Jean-Marc Bourguet <jm@bourguet.org> wrote: >>>> >>>> It's also apparently assumed by Microsoft, and is required by the >>>> new C++ standard. >>> >>>Not true. >> >> Er, which is not true, and what is your evidence for saying that? >> The first was hearsay, from a usually reliable source, on WG21; >> that is why I said "apparently". If you want to challenge me on >> the latter, please feel free :-) I was somewhat involved, though >> not a major player. > >Either you or I misunderstand something. The section "1.10 Multi-threaded >executions and data races" seems to me to define a model more relaxed than >sequential consistency. It does seem to, but that is more in appearance than actuality. The point is that it does not require ANY consistency except among properly synchronised usage, and memory_order_seq_cst is a required (and the recommended) form for atomic operations. I am pretty sure (and understood Hans Boehm to confirm it) that any program that uses only ordinary and memory_order_seq_cst operations is either sequentially consistent or undefined. The point is that the compiler cannot tell what data accesses should be synchronised by a memory_order_seq_cst atomic operation (in general) and therefore must synchronise everything. It is a more relaxed model only in that sequential consistency is not required for improperly synchronised usage, which is undefined. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-26 13:15 -0700 |
| Message-ID | <61189b3a-d0ac-44d1-9925-29f46c59aed9@v15g2000vbm.googlegroups.com> |
| In reply to | #4408 |
On Oct 26, 9:53 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> wrote: > On 10/26/2011 9:07 AM, Michael S wrote: > > > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: > > >> Er, try a Web search for "sequential consistency" and look at the > >> first hit. > > > Nice definition, but absolutely impractical as main memory sequencing > > model. It looks impossible to implement in efficient manner on CMP/SMP > > with distributed caches and/or on any sorts of NUMA, even the > > cacheless ones. > > Interesting. > > It's the memory model for IBM mainframes. Newer IBM mainframe cores have private write-back caches, right? And they had NUMA + write-through caches for decades, right? If, despite that, they really managed to achieve "sequential consistency" as defined by Wikipedia article (and by Nick's example) without very serious performance impact, then their microarchitects are way smarter than I am. Which is almost certainly true :(
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-10-27 04:10 -0700 |
| Message-ID | <489529f0-fde0-4aa9-b4c8-c543d1e71975@i19g2000yqf.googlegroups.com> |
| In reply to | #4412 |
On Oct 26, 10:15 pm, Michael S <already5cho...@yahoo.com> wrote: > On Oct 26, 9:53 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> > wrote: > > > On 10/26/2011 9:07 AM, Michael S wrote: > > > > On Oct 26, 4:42 pm, n...@cam.ac.uk wrote: > > > >> Er, try a Web search for "sequential consistency" and look at the > > >> first hit. > > > > Nice definition, but absolutely impractical as main memory sequencing > > > model. It looks impossible to implement in efficient manner on CMP/SMP > > > with distributed caches and/or on any sorts of NUMA, even the > > > cacheless ones. > > > Interesting. > > > It's the memory model for IBM mainframes. > > Newer IBM mainframe cores have private write-back caches, right? > And they had NUMA + write-through caches for decades, right? > If, despite that, they really managed to achieve "sequential > consistency" as defined by Wikipedia article (and by Nick's example) > without very serious performance impact, then their microarchitects > are way smarter than I am. > Which is almost certainly true :( I tried to think a bit more about it. May be, sequential consistency is not as hard to implement as I initially imagined. Current x86 multiprocessor implementations (with possible exception of the new SGI Altix-UV) are pretty close to it already. Unofficially they conform to a model that I'd call "N-2 sequential consistency" described as: "...for every arbitrary couple of processors in the system, the result of any execution is the same as if the operations of all *other* the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program." I'd imagine that on current x86 multiprocessors (with possible exception of the new SGI Altix-UV) all transaction of cache lines ownership *are* globally ordered. So I'd think that there is only one feature in current x86 multiprocessors that prevents them from being true sequentially consistent - load to different memory location can be completed before the preceding store made globally visible. Removal of that feature will certainly impact performance, but probably by factor of less than 2. On the same line of thought, I'd imagine that Sun/Oracle Niagara line of CPUs provides sequential consistency right now, although they likely wouldn't want to officially confirm that.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.arch
csiph-web