Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #2242
| Followup-To | comp.programming.threads, comp.programming, comp.arch |
|---|---|
| From | Chris Gray <cg@GraySage.COM> |
| Newsgroups | comp.programming.threads, comp.programming, comp.arch |
| Subject | Re: About lockfree and waitfree... (2nd try) |
| References | <lif821$inj$1@news.albasani.net> <lj933b$i85$1@dont-email.me> <lj94gr$c41$1@needham.csi.cam.ac.uk> <lj97cc$hfk$1@dont-email.me> <lj994h$n3c$1@needham.csi.cam.ac.uk> |
| Message-ID | <87y4yu654p.fsf@GraySage.COM> (permalink) |
| Organization | Gray Sage Holdings |
| Date | 2014-04-24 10:53 -0600 |
Cross-posted to 3 groups.
Followups directed to: comp.programming.threads, comp.programming, comp.arch
nmm@needham.csi.cam.ac.uk (Nick Maclaren) writes: > Yes :-) Simply getting distinct sequences of keys with each thread's > sequence sequential is easy, but not very useful. Your description > is correct, but incomplete, because there is also the requirement > for sequential consistency. And some (many?) algorithms that want > numbers of that form want them consistent with memory accesses. I promised myself I wouldn't post on this group, since I'm not qualified, but I've been thinking about this one. I too am a software guy. What exactly does "sequential consistency" mean? Does it mean that successive reads of the TAN facility return a strict counting sequence of values? If so, then I certainly can't see any kind of realistic solution. If, however, you only need successive reads by a given reader to always return increasing values, and that reads by different readers never return the same value, then Stephen's solution looks good to me. I had thought that the only consistency needed was what it provides. Other systems use simple clock registers, and using those there can be other ways in which gaps can appear in the sequence as read by any given reader. Note that Stephen's solution does create a global ordering among all of the requesters, and that ordering makes sense temporally. There is nothing said about the ordering received by different requesters that make their requests "at the same time", but that pretty much has to be the case. The solution decides that ordering based on the per-"register" ID bits. Now as a software guy, I also wonder about the implementability of this stuff at the hardware level. If a "register" has two parts, and the two parts are updated by independent mechanisms, when is the register stable? This is especially important if one part is being decreased and a higher part is being increased. It's the same as a simple counter, in that you have to read the value after the carry has propagated all the way to the top of the register. Since that works, I assume Stephen's scheme can work too. Perhaps the HW guys just design things so that values are stable by the first half of a cycle, and all reads are done in the second half of the cycle, or some such. I also wonder about the ideas of a counter being updated on a read. My naive view of registers (or belt positions) was that they could just be gated onto buses as needed. If readers are supposed to get different values, such a setup won't work. What if multiple readers on a multiple issue core request a value during the same cycle? How can the hardware guarantee they all get different values? You would have to expand Stephen's solution to provide a separate TAN source for each execution unit. -- Chris Gray
Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
About lockfree and waitfree... aminer <aminer@toto.net> - 2014-04-13 19:54 -0700
Re: About lockfree and waitfree... "Chris M. Thomasson" <no@spam.invalid> - 2014-04-13 19:38 -0700
Re: About lockfree and waitfree... "Chris M. Thomasson" <no@spam.invalid> - 2014-04-13 19:47 -0700
Re: About lockfree and waitfree... aminer <aminer@toto.net> - 2014-04-13 22:56 -0700
Re: About lockfree and waitfree... "Chris M. Thomasson" <no@spam.invalid> - 2014-04-14 14:08 -0700
Re: About lockfree and waitfree... "Chris M. Thomasson" <no@spam.invalid> - 2014-04-14 14:23 -0700
Re: About lockfree and waitfree... Ivan Godard <ivan@ootbcomp.com> - 2014-04-14 16:27 -0700
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-14 16:29 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-15 10:04 -0700
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-15 10:34 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-17 16:35 -0700
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-17 17:04 -0700
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-18 09:54 +0100
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-18 02:31 -0700
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-18 11:56 +0100
Re: About lockfree and waitfree... (2nd try) rpw3@rpw3.org (Rob Warnock) - 2014-04-18 11:26 +0000
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-18 13:30 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-21 14:25 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-21 14:31 -0700
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-21 14:53 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-22 14:21 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-22 14:36 -0700
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-22 15:30 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-05-01 00:48 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-05-25 13:16 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-21 14:34 -0700
Re: About lockfree and waitfree... (2nd try) Robert Wessel <robertwessel2@yahoo.com> - 2014-04-21 16:42 -0500
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-21 15:02 -0700
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-22 09:05 +0100
Re: About lockfree and waitfree... (2nd try) Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2014-04-22 09:27 -0700
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-22 09:45 -0700
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-22 18:08 +0100
Re: About lockfree and waitfree... (2nd try) Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2014-04-23 12:08 -0700
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-23 20:32 +0100
Re: About lockfree and waitfree... (2nd try) Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2014-04-23 13:21 -0700
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-23 21:51 +0100
Re: About lockfree and waitfree... (2nd try) Chris Gray <cg@GraySage.COM> - 2014-04-24 10:53 -0600
Re: About lockfree and waitfree... (2nd try) nmm@needham.csi.cam.ac.uk (Nick Maclaren) - 2014-04-24 18:02 +0100
Re: About lockfree and waitfree... (2nd try) Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2014-04-25 13:39 -0700
Re: About lockfree and waitfree... (2nd try) "Chris M. Thomasson" <no@spam.invalid> - 2014-04-22 22:08 -0700
Re: About lockfree and waitfree... (2nd try) George Neuner <gneuner2@comcast.net> - 2014-04-17 21:15 -0400
Re: About lockfree and waitfree... (2nd try) George Neuner <gneuner2@comcast.net> - 2014-04-17 21:25 -0400
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-17 19:17 -0700
Re: About lockfree and waitfree... (2nd try) George Neuner <gneuner2@comcast.net> - 2014-04-18 00:46 -0400
Re: About lockfree and waitfree... (2nd try) Ivan Godard <ivan@ootbcomp.com> - 2014-04-17 18:52 -0700
Re: About lockfree and waitfree... aminer <aminer@toto.net> - 2014-04-13 22:54 -0700
csiph-web