Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #122048 > unrolled thread
| Started by | Muttley@DastardlyHQ.org |
|---|---|
| First post | 2025-03-30 08:57 +0000 |
| Last post | 2025-04-02 10:29 +0200 |
| Articles | 18 on this page of 78 — 13 participants |
Back to article view | Back to comp.lang.c++
Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 08:57 +0000
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-30 07:21 -0400
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 16:22 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 19:56 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:00 +0000
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-30 10:38 -0400
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 15:30 +0000
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 15:59 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 16:09 +0000
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 16:17 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-30 16:23 +0000
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 16:26 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-31 08:20 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 10:46 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 11:56 +0300
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 11:11 +0200
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-31 07:25 -0400
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 15:26 +0300
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 14:32 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 15:44 +0300
Re: Pre-main construction order in modules Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-04-01 06:06 +0200
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 08:41 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 11:41 +0300
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-31 07:22 -0400
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-30 15:05 -0400
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 19:58 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:02 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 20:05 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:07 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 20:08 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:11 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 20:17 +0200
Re: Pre-main construction order in modules Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-30 18:20 +0000
Re: Pre-main construction order in modules Richard Damon <richard@damon-family.org> - 2025-03-30 15:01 -0400
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-30 22:15 +0200
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-30 13:57 -0700
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 07:37 +0200
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-31 21:54 -0700
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 08:41 +0200
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 00:00 -0700
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 11:42 +0200
Re: Pre-main construction order in modules "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-04-01 12:00 +0200
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 14:16 +0200
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 16:03 +0200
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 11:49 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-31 09:09 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 15:39 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-03-31 14:01 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-03-31 20:06 +0300
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-31 19:42 -0400
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 07:26 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 11:48 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 08:57 +0000
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 12:21 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:08 +0000
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 13:12 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:23 +0000
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:27 +0000
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 13:20 +0300
Re: Pre-main construction order in modules Paavo Helde <eesnimi@osa.pri.ee> - 2025-04-01 13:33 +0300
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-01 10:48 +0000
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 14:37 -0400
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 14:37 -0400
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 14:32 -0400
Re: Pre-main construction order in modules "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 12:39 -0700
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 23:26 +0300
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 19:08 -0400
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 22:55 -0400
Re: Pre-main construction order in modules Muttley@DastardlyHQ.org - 2025-04-02 07:34 +0000
Re: Pre-main construction order in modules scott@slp53.sl.home (Scott Lurndal) - 2025-03-31 14:15 +0000
Re: Pre-main construction order in modules Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-31 16:47 +0200
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-31 10:29 -0400
Re: Pre-main construction order in modules Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-04-01 06:29 +0200
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 13:55 -0400
Re: Pre-main construction order in modules Michael S <already5chosen@yahoo.com> - 2025-04-01 23:10 +0300
Re: Pre-main construction order in modules Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-01 14:20 -0700
Re: Pre-main construction order in modules James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-01 18:57 -0400
Re: Pre-main construction order in modules David Brown <david.brown@hesbynett.no> - 2025-04-02 10:29 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-01 10:48 +0000 |
| Message-ID | <vsggah$2ts5v$1@dont-email.me> |
| In reply to | #122112 |
On Tue, 1 Apr 2025 13:33:43 +0300 Paavo Helde <eesnimi@osa.pri.ee> wibbled: >On 01.04.2025 13:20, Michael S wrote: >> On Tue, 1 Apr 2025 11:48:23 +0300 >> Paavo Helde <eesnimi@osa.pri.ee> wrote: >> >>> >>> Welcome to the 21-st century where out-of-sync CPU caches and >>> pipelines are the norm. >>> >>> >> >> It seems to me that saying that events are "strongly ordered" makes >> sense only when "weakly ordered" and "unordered" are not the same. >> In this particular case I don't see how exactly "weakly ordered" >> differs from "unordered". > >The standard defines the terms "happens before", "simply happens >before", and "strongly happens before". The standard does not contain Those phrases all mean the same thing.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 14:37 -0400 |
| Message-ID | <vshbpu$362ev$1@dont-email.me> |
| In reply to | #122109 |
On 4/1/25 06:20, Michael S wrote: ... > It seems to me that saying that events are "strongly ordered" makes > sense only when "weakly ordered" and "unordered" are not the same. > In this particular case I don't see how exactly "weakly ordered" > differs from "unordered". The term is "happens before", not "ordered". The standard defines neither "weakly happens before" nor anything connected to "happens before" that would be analogous to "unordered". See my response else-thread for more details on the relevant definitions.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 14:37 -0400 |
| Message-ID | <vshbpq$362k4$3@dont-email.me> |
| In reply to | #122109 |
On 4/1/25 06:20, Michael S wrote: ... > It seems to me that saying that events are "strongly ordered" makes > sense only when "weakly ordered" and "unordered" are not the same. > In this particular case I don't see how exactly "weakly ordered" > differs from "unordered". The term is "happens before", not "ordered". The standard defines neither "weakly happens before" nor anything connected to "happens before" that would be analogous to "unordered". See my response else-thread for more details on the relevant definitions.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 14:32 -0400 |
| Message-ID | <vshbgm$362k4$2@dont-email.me> |
| In reply to | #122100 |
On 01.04.2025 10:26, Muttley@DastardlyHQ.org wrote: > On Mon, 31 Mar 2025 19:42:48 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >> On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote: >>> On Mon, 31 Mar 2025 15:39:53 +0300 >>> Paavo Helde <eesnimi@osa.pri.ee> wibbled: >>>> On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote: >>>> "If [initialization] is deferred, it strongly happens before any >>>> non-initialization odr-use of any non-inline function or non-inline >>>> variable defined in the same translation unit as the variable to be >>>> initialized." >>> >>> Who writes this stuff? Its borderline gibberish. >> >> Keep in mind that the key thing that makes this seem like gibberish is >> the use of precisely defined technical jargon, which is used for the >> same reason that jargon is used in many other contexts: it has a more >> precisely specified meaning than more informal wording would have had. >> >> Key pieces of jargon: "strongly happens before", "non-initialization", > > "strongly happens before" is genuine gibberish. Either something happens before > or it doesn't, the adverb is entirely superfluous. Terms are explicitly defined by the C++ standard precisely because their meaning cannot be inferred by using ordinary English to interpret the words that make them up. Both "happens before" and "strongly happens before" are separate pieces of C++ jargon, and the requirements for qualifying as "strongly happens before" are in fact stronger than those for "happens before". "An evaluation A happens before an evaluation B (or, equivalently, B happens after A) if: (10.1)— A is sequenced before B, or (10.2)— A inter-thread happens before B. The implementation shall ensure that no program execution demonstrates a cycle in the “happens before” relation. [Note: This cycle would otherwise be possible only through the use of consume operations. — end note]" (6.9.2.1p10). the first occurrence of "happens before" in that clause is in italics, an ISO convention indicating that it is a piece of specialized jargon whose definition is provided by the sentence in which it occurs. Note that "sequenced before" and "inter-thread happens before" are two other pieces of standard-defined jargon. "An evaluation A strongly happens before an evaluation D if, either (12.1)— A is sequenced before D, or (12.2)— A synchronizes with D, and both A and D are sequentially consistent atomic operations (31.4), or (12.3)— there are evaluations B and C such that A is sequenced before B, B simply happens before C, and C is sequenced before D, or (12.4)— there is an evaluation B such that A strongly happens before B, and B strongly happens before D. [Note: Informally, if A strongly happens before B, then A appears to be evaluated before B in all contexts. Strongly happens before excludes consume operations. — end note]" The first occurrence of "strongly happens before" in that clause is also italicized. Note that "A is sequenced before D" would be sufficient to ensure that both "A happens before D" and "A strongly happens before D" are true. The difference between the two terms only shows up if A is not sequenced before D. In that case, at a minimum you must have "A inter-thread happens before D", but is not synchronized with D. For instance A inter-thread happens before D if it is dependency-ordered before D. (6.9.2.1p9). This could happen if A performs a release operation on an atomic object M , and, in another thread, D performs a consume operation on M and reads the value written by A (6.9.2.1p8). In that case, the requirements associated with "A happens before D" must be met, but those associated with "A strongly happens before D" need not be. Do you need an explanation of the parts of the above explanation that use the terms "release" and "consume"? I have little experience with multi-threaded code - someone else might be able to explain those better than I can.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-04-01 12:39 -0700 |
| Message-ID | <vshfcs$3smrc$1@dont-email.me> |
| In reply to | #122117 |
On 4/1/2025 11:32 AM, James Kuyper wrote: > On 01.04.2025 10:26, Muttley@DastardlyHQ.org wrote: >> On Mon, 31 Mar 2025 19:42:48 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >>> On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote: >>>> On Mon, 31 Mar 2025 15:39:53 +0300 >>>> Paavo Helde <eesnimi@osa.pri.ee> wibbled: >>>>> On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote: >>>>> "If [initialization] is deferred, it strongly happens before any >>>>> non-initialization odr-use of any non-inline function or non-inline >>>>> variable defined in the same translation unit as the variable to be >>>>> initialized." >>>> >>>> Who writes this stuff? Its borderline gibberish. >>> >>> Keep in mind that the key thing that makes this seem like gibberish is >>> the use of precisely defined technical jargon, which is used for the >>> same reason that jargon is used in many other contexts: it has a more >>> precisely specified meaning than more informal wording would have had. >>> >>> Key pieces of jargon: "strongly happens before", "non-initialization", >> >> "strongly happens before" is genuine gibberish. Either something happens before >> or it doesn't, the adverb is entirely superfluous. > > Terms are explicitly defined by the C++ standard precisely because their > meaning cannot be inferred by using ordinary English to interpret the > words that make them up. Both "happens before" and "strongly happens > before" are separate pieces of C++ jargon, and the requirements for > qualifying as "strongly happens before" are in fact stronger than those > for "happens before". > > "An evaluation A happens before an evaluation B (or, equivalently, B > happens after A) if: > (10.1)— A is sequenced before B, or > (10.2)— A inter-thread happens before B. > The implementation shall ensure that no program execution demonstrates a > cycle in the “happens before” relation. [Note: This cycle would > otherwise be possible only through the use of consume operations. — end > note]" (6.9.2.1p10). > > the first occurrence of "happens before" in that clause is in italics, > an ISO convention indicating that it is a piece of specialized jargon > whose definition is provided by the sentence in which it occurs. Note > that "sequenced before" and "inter-thread happens before" are two other > pieces of standard-defined jargon. > > "An evaluation A strongly happens before an evaluation D if, either > (12.1)— A is sequenced before D, or > (12.2)— A synchronizes with D, and both A and D are sequentially > consistent atomic operations (31.4), or > (12.3)— there are evaluations B and C such that A is sequenced before B, > B simply happens before C, and C is sequenced before D, or > (12.4)— there is an evaluation B such that A strongly happens before B, > and B strongly happens before D. > [Note: Informally, if A strongly happens before B, then A appears to be > evaluated before B in all contexts. Strongly happens before excludes > consume operations. — end note]" > > The first occurrence of "strongly happens before" in that clause is also > italicized. > > Note that "A is sequenced before D" would be sufficient to ensure that > both "A happens before D" and "A strongly happens before D" are true. > The difference between the two terms only shows up if A is not sequenced > before D. In that case, at a minimum you must have "A inter-thread > happens before D", but is not synchronized with D. > > For instance A inter-thread happens before D if it is dependency-ordered > before D. (6.9.2.1p9). This could happen if A performs a release > operation on an atomic object M , and, in another thread, D performs a > consume operation on M and reads the value written by A (6.9.2.1p8). > > In that case, the requirements associated with "A happens before D" must > be met, but those associated with "A strongly happens before D" need not be. > > Do you need an explanation of the parts of the above explanation that > use the terms "release" and "consume"? I have little experience with > multi-threaded code - someone else might be able to explain those better > than I can. Consume is weaker than acquire. It is basically used for data-dependent loads. For instance, it can be used for RCU algorithms that do not need a full acquire barrier. Now, iirc, the only system that actually needs an explicit barrier for data-dependent loads is the dec alpha. Actually, it kind of seems like consume was meant for RCU like algos.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-01 23:26 +0300 |
| Message-ID | <20250401232600.00002eb6@yahoo.com> |
| In reply to | #122117 |
On Tue, 1 Apr 2025 14:32:54 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 01.04.2025 10:26, Muttley@DastardlyHQ.org wrote: > > On Mon, 31 Mar 2025 19:42:48 -0400 > > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: > >> On 31.03.2025 17:01, Muttley@DastardlyHQ.org wrote: > >>> On Mon, 31 Mar 2025 15:39:53 +0300 > >>> Paavo Helde <eesnimi@osa.pri.ee> wibbled: > >>>> On 31.03.2025 12:09, Muttley@DastardlyHQ.org wrote: > >>>> "If [initialization] is deferred, it strongly happens before any > >>>> non-initialization odr-use of any non-inline function or > >>>> non-inline variable defined in the same translation unit as the > >>>> variable to be initialized." > >>> > >>> Who writes this stuff? Its borderline gibberish. > >> > >> Keep in mind that the key thing that makes this seem like > >> gibberish is the use of precisely defined technical jargon, which > >> is used for the same reason that jargon is used in many other > >> contexts: it has a more precisely specified meaning than more > >> informal wording would have had. > >> > >> Key pieces of jargon: "strongly happens before", > >> "non-initialization", > > > > "strongly happens before" is genuine gibberish. Either something > > happens before or it doesn't, the adverb is entirely superfluous. > > Terms are explicitly defined by the C++ standard precisely because > their meaning cannot be inferred by using ordinary English to > interpret the words that make them up. Both "happens before" and > "strongly happens before" are separate pieces of C++ jargon, and the > requirements for qualifying as "strongly happens before" are in fact > stronger than those for "happens before". > > "An evaluation A happens before an evaluation B (or, equivalently, B > happens after A) if: > (10.1)— A is sequenced before B, or > (10.2)— A inter-thread happens before B. > The implementation shall ensure that no program execution > demonstrates a cycle in the “happens before” relation. [Note: This > cycle would otherwise be possible only through the use of consume > operations. — end note]" (6.9.2.1p10). > > the first occurrence of "happens before" in that clause is in italics, > an ISO convention indicating that it is a piece of specialized jargon > whose definition is provided by the sentence in which it occurs. Note > that "sequenced before" and "inter-thread happens before" are two > other pieces of standard-defined jargon. > > "An evaluation A strongly happens before an evaluation D if, either > (12.1)— A is sequenced before D, or > (12.2)— A synchronizes with D, and both A and D are sequentially > consistent atomic operations (31.4), or > (12.3)— there are evaluations B and C such that A is sequenced before > B, B simply happens before C, and C is sequenced before D, or > (12.4)— there is an evaluation B such that A strongly happens before > B, and B strongly happens before D. > [Note: Informally, if A strongly happens before B, then A appears to > be evaluated before B in all contexts. Strongly happens before > excludes consume operations. — end note]" > > The first occurrence of "strongly happens before" in that clause is > also italicized. > > Note that "A is sequenced before D" would be sufficient to ensure that > both "A happens before D" and "A strongly happens before D" are true. > The difference between the two terms only shows up if A is not > sequenced before D. In that case, at a minimum you must have "A > inter-thread happens before D", but is not synchronized with D. > > For instance A inter-thread happens before D if it is > dependency-ordered before D. (6.9.2.1p9). This could happen if A > performs a release operation on an atomic object M , and, in another > thread, D performs a consume operation on M and reads the value > written by A (6.9.2.1p8). > > In that case, the requirements associated with "A happens before D" > must be met, but those associated with "A strongly happens before D" > need not be. > You probably paid attentions that the text is not crystal clear. It looks like authors of the Standard invent their own terminology not only when absolutely necessary but sometimes even when there exist established terms for the same things. To their defense, I could say that in the branch of CS that is related to concurrency and parallelism very few terms are 100% consensus. > Do you need an explanation of the parts of the above explanation that > use the terms "release" and "consume"? I have little experience with > multi-threaded code - someone else might be able to explain those > better than I can. > I suspected that the difference between "strong happens before" and "happens before" is somehow related to implied ordering due to causality. After reading the text above my feeling changed from suspicion to strong suspicion. But it is not yet a certainty.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 19:08 -0400 |
| Message-ID | <vshrkp$6kb9$1@dont-email.me> |
| In reply to | #122122 |
On 4/1/25 16:26, Michael S wrote: ... > You probably paid attentions that the text is not crystal clear. > It looks like authors of the Standard invent their own terminology not > only when absolutely necessary but sometimes even when there exist > established terms for the same things. To their defense, I could say > that in the branch of CS that is related to concurrency and parallelism > very few terms are 100% consensus. Feel free to propose alternative wording with the same precise meaning. Keep in mind that these terms were invented to convey a more precisely-define meaning than existing terms would have provided, so wording that says "approximately" the same thing would not be an acceptable replacement. ... > I suspected that the difference between "strong happens before" and > "happens before" is somehow related to implied ordering due to > causality. After reading the text above my feeling changed from > suspicion to strong suspicion. But it is not yet a certainty. I'm no expert in multi-threaded code, so I don't fully understand the significance of what it says. However, I able to derive the fact that there is a difference between the two terms only when one evaluation "inter-thread happens before" another evaluation, and the two evaluations are not synchronized. In other words, the difference is with regard to what's required for unsynchronized threads.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 22:55 -0400 |
| Message-ID | <vsi8vs$k7j9$1@dont-email.me> |
| In reply to | #122117 |
On 4/1/25 14:32, James Kuyper wrote: ... > Note that "A is sequenced before D" would be sufficient to ensure that > both "A happens before D" and "A strongly happens before D" are true. > The difference between the two terms only shows up if A is not sequenced > before D. In that case, at a minimum you must have "A inter-thread > happens before D", but is not synchronized with D. > > For instance A inter-thread happens before D if it is dependency-ordered > before D. (6.9.2.1p9). This could happen if A performs a release > operation on an atomic object M , and, in another thread, D performs a > consume operation on M and reads the value written by A (6.9.2.1p8). I got sidetracked by life before I could look into that further, but I've traced down relevant text in 1.10p7: "An evaluation A that performs a release operation on an object M synchronizes with an evaluation B that performs an acquire operation on M and reads a value written by any side effect in the release sequence headed by A." Therefore, A "happens before" D, but does not "strongly happen before" D if A does a release on M, and D does a consume on M, but D does not do an acquire on M followed by reading a value written by a side effect of A's release sequence.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-04-02 07:34 +0000 |
| Message-ID | <vsipas$199of$1@dont-email.me> |
| In reply to | #122117 |
On Tue, 1 Apr 2025 14:32:54 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >"An evaluation A strongly happens before an evaluation D if, either : >(12.4)— there is an evaluation B such that A strongly happens before B, >and B strongly happens before D. Looks like a circular definition to me. But regardless, looks like the usual unintelligable nonsense thats no use to anyone except the people who wrote it. >Do you need an explanation of the parts of the above explanation that >use the terms "release" and "consume"? I have little experience with >multi-threaded code - someone else might be able to explain those better >than I can. I don't particularly care. I generally find standards and RFCs unreadable. Its often easier to look at code or test with a working example to see what actually happens. Thats the method I used to write my NNTP and NMAP clients amongst many others.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-31 14:15 +0000 |
| Message-ID | <bsxGP.350150$sbY2.196414@fx40.iad> |
| In reply to | #122077 |
Paavo Helde <eesnimi@osa.pri.ee> writes: >On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote: >> On Sun, 30 Mar 2025 10:38:57 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >>> Section 6.9.3.3 does in fact impose many constraints on the sequence in >>> which non-local objects with static storage duration get initialized. >>> However, all of the sequence requirements are only between objects >>> defined in the same translation unit. Also, it's implementation-defined >>> which of those initializations occur before the start of main(). >> >> Initialising global objects before main is an absolute must otherwise how >> are you expected to use them safely? They're not in the code for decoration. > >Initializing global objects before main is not possible with >demand-loaded dynamically loaded libraries. Which are initialized as the library is loaded. Much the same effect as implementing before main.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-03-31 16:47 +0200 |
| Message-ID | <vse9sl$hhbh$1@raubtier-asyl.eternal-september.org> |
| In reply to | #122088 |
Am 31.03.2025 um 16:15 schrieb Scott Lurndal: > Which are initialized as the library is loaded. Much the > same effect as implementing before main. It looks somewhat strange to me to get the address of an export which is not a function with dladdr or GetProcAddress. I think the usual case would be that the dynamic library uses global objects for its own use.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-03-31 10:29 -0400 |
| Message-ID | <vse8sj$f9o2$1@dont-email.me> |
| In reply to | #122051 |
On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote: > On Sun, 30 Mar 2025 10:38:57 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >> Section 6.9.3.3 does in fact impose many constraints on the sequence in >> which non-local objects with static storage duration get initialized. >> However, all of the sequence requirements are only between objects >> defined in the same translation unit. Also, it's implementation-defined >> which of those initializations occur before the start of main(). > > Initialising global objects before main is an absolute must otherwise how > are you expected to use them safely? They're not in the code for decoration. "If it [initialization] is deferred, it strongly happens before any non-initialization odr-use of any non-inline function or non-inline variable defined in the same translation unit as the variable to be initialized.47 It is implementation-defined in which threads and at which points in the program such deferred dynamic initialization occurs." (6.9.3.3p5). Therefore, what you need to do is make sure that the object has been initialized is to access it from a function defined in the same translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Jakob Bohm <egenagwemdimtapsar@jbohm.dk> |
|---|---|
| Date | 2025-04-01 06:29 +0200 |
| Message-ID | <vsfq2q$26s1t$1@dont-email.me> |
| In reply to | #122089 |
On 2025-03-31 16:29, James Kuyper wrote: > On 30.03.2025 18:30, Muttley@DastardlyHQ.org wrote: >> On Sun, 30 Mar 2025 10:38:57 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wibbled: >>> Section 6.9.3.3 does in fact impose many constraints on the sequence in >>> which non-local objects with static storage duration get initialized. >>> However, all of the sequence requirements are only between objects >>> defined in the same translation unit. Also, it's implementation-defined >>> which of those initializations occur before the start of main(). >> >> Initialising global objects before main is an absolute must otherwise how >> are you expected to use them safely? They're not in the code for decoration. > > "If it [initialization] is deferred, it strongly happens before any > non-initialization odr-use of any non-inline function or non-inline > variable defined in the same translation unit as the variable to be > initialized.47 It is implementation-defined in which threads and at > which points in the program such deferred dynamic initialization > occurs." (6.9.3.3p5). > > Therefore, what you need to do is make sure that the object has been > initialized is to access it from a function defined in the same > translation unit. > The literalist reading of that wording fails miserably if a real world program uses a global constructor/initializer to cause some desired imperative effect outside the C++ runtime state. Examples include setting the CPU clock frequency of a small system, outputting some kind of welcome message to the human user etc. etc. However treating the standard text as an imperfect description of traditional compiler techniques used for 2nd. Edition compilers makes much more sense . Those guarantee that all included global objects are constructed before the first line of the main/init function of the linker output unit (program, dll, driver, whatever) and destructed after the last line of the main/cleanup function of the same . Even if either of those functions are implicit default empty functions . Just like if those globals were member objects of an implied program class where main/init/cleanup are member/constructor/destructor functions . Note that my previous paragraph accepts the possibility of some global objects getting optimized away completely along with their compilation unit by things like using a static library containing those compilation units . Enjoy Jakob -- Jakob Bohm, MSc.Eng., I speak only for myself, not my company This public discussion message is non-binding and may contain errors All trademarks and other things belong to their owners, if any.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 13:55 -0400 |
| Message-ID | <vsh9av$362k4$1@dont-email.me> |
| In reply to | #122094 |
On 4/1/25 00:29, Jakob Bohm wrote: > On 2025-03-31 16:29, James Kuyper wrote: ... >> "If it [initialization] is deferred, it strongly happens before any >> non-initialization odr-use of any non-inline function or non-inline >> variable defined in the same translation unit as the variable to be >> initialized.47 It is implementation-defined in which threads and at >> which points in the program such deferred dynamic initialization >> occurs." (6.9.3.3p5). >> >> Therefore, what you need to do is make sure that the object has been >> initialized is to access it from a function defined in the same >> translation unit. >> > > The literalist reading of that wording fails miserably if a real world > program uses a global constructor/initializer to cause some desired > imperative effect outside the C++ runtime state. Examples include > setting the CPU clock frequency of a small system, outputting some kind > of welcome message to the human user etc. etc. The wording describes what C++ does and does not require of an implementation. What actual implementations do is a different issue. If an implementation doesn't do what's required of it, it's non-conforming. If a program expects more than is required, the behavior of that code is undefined, which includes the possibility that the code will work exactly as intended if translated by an implementation that does, in fact, do more than what is required. > However treating the standard text as an imperfect description of > traditional compiler techniques used for 2nd. Edition compilers makes > much more sense . No, that does not. The standard was never intended as a description of how compilers actually work, it was always intended to be a description of requirements on how they should work.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-01 23:10 +0300 |
| Message-ID | <20250401231040.00007eeb@yahoo.com> |
| In reply to | #122116 |
On Tue, 1 Apr 2025 13:55:43 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 4/1/25 00:29, Jakob Bohm wrote: > > > However treating the standard text as an imperfect description of > > traditional compiler techniques used for 2nd. Edition compilers > > makes much more sense . > > No, that does not. The standard was never intended as a description of > how compilers actually work, it was always intended to be a > description of requirements on how they should work. It sounds to me like a revisionisms. Most language standards are intended to codify commonalities of work of existing compilers. That applies to C++98 and mostly, although not completely, to the following C++ standards. There exist exceptions, for example, Ada83. But they are exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-01 14:20 -0700 |
| Message-ID | <87h637poi6.fsf@nosuchdomain.example.com> |
| In reply to | #122121 |
Michael S <already5chosen@yahoo.com> writes:
> On Tue, 1 Apr 2025 13:55:43 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/1/25 00:29, Jakob Bohm wrote:
>> > However treating the standard text as an imperfect description of
>> > traditional compiler techniques used for 2nd. Edition compilers
>> > makes much more sense .
>>
>> No, that does not. The standard was never intended as a description of
>> how compilers actually work, it was always intended to be a
>> description of requirements on how they should work.
>
> It sounds to me like a revisionisms.
> Most language standards are intended to codify commonalities of work of
> existing compilers. That applies to C++98 and mostly, although not
> completely, to the following C++ standards.
I disagree. Many language standards are *based on* the behavior
of existing compilers. In the case of C, for example, there were
multiple implementations before the first standard was published, and
the standard was largely based on their behavior (and on K&R1). The
C++ standard evolved similarly; there were several implementations
and books before the first C++ standard was published.
But once a standard is published, it is a set of requirements on
conforming implementations and programs. Note in particular that
standards typically don't mention any specific implementations,
and that implementations have had to be changed to satisfy the
standard's requirements.
I think of a language standard as a proposed contract between
implementers and programmers. If an implementation claims
conformance, programmers have a right to expect conforming code to
behave as specified by the standard. But neither implementers nor
programmers are necessarily required to accept the contract.
> There exist exceptions, for example, Ada83. But they are exceptions.
Ada 83 was unusual in the sense that the standard was deliberately
developed first, and implementations followed (though a lot of it
was based on other existing languages). But once published, the
Ada standard served much the same purpose as the C and C++ standards.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-01 18:57 -0400 |
| Message-ID | <vshr0o$6kba$1@dont-email.me> |
| In reply to | #122121 |
On 4/1/25 16:10, Michael S wrote: > On Tue, 1 Apr 2025 13:55:43 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: ... >> No, that does not. The standard was never intended as a description of >> how compilers actually work, it was always intended to be a >> description of requirements on how they should work. > > > It sounds to me like a revisionisms. > Most language standards are intended to codify commonalities of work of > existing compilers. That applies to C++98 and mostly, although not > completely, to the following C++ standards. Regardless of whether they codify existing implementations or innovate far beyond them, programming language standards are codifications - and that makes them prescriptive documents. The C++ standard exists to define what it means to be a conforming implementation of C++, and what it means to write well-formed code. Well-formed code translated by a conforming implementation of C++ will produce the behavior that meets the requirements specified by the standard - and that's the point of the standard. However, C++98 was in fact notorious for the extent to which it went beyond merely codifying existing practice. In particular, <iostream> was a big change from <iostream.h>, and the process of incorporating STL into the C++ standard library involved a lot of changes. And every revision to the C++ standard has increased C++'s reputation for innovating well beyond existing practice. The language defined by the latest standard is very different from the one defined by C++98. The other standard that I'm most familiar with, the C standard, is by comparison a very slowly changing standard - but C90, C99, and C2011 were all pretty significant changes from existing practice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-02 10:29 +0200 |
| Message-ID | <vsisgt$1bk1v$1@dont-email.me> |
| In reply to | #122121 |
On 01/04/2025 22:10, Michael S wrote: > On Tue, 1 Apr 2025 13:55:43 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> On 4/1/25 00:29, Jakob Bohm wrote: > >> >>> However treating the standard text as an imperfect description of >>> traditional compiler techniques used for 2nd. Edition compilers >>> makes much more sense . >> >> No, that does not. The standard was never intended as a description of >> how compilers actually work, it was always intended to be a >> description of requirements on how they should work. > > > It sounds to me like a revisionisms. > Most language standards are intended to codify commonalities of work of > existing compilers. That applies to C++98 and mostly, although not > completely, to the following C++ standards. > There exist exceptions, for example, Ada83. But they are exceptions. > Most language standards /started/ with a codification of existing tools. Making a language standard is a lot of effort, and is rarely done until there is at least one implementation and it has been used for a while - there's little point spending a lot of time defining a language that might never be used, or might turn out to be impractical or inefficient to implement. Initial standards are often books - K&R "The C Programming Language" and Stroustrup "The C++ Programming Language" being fine examples. More official standards can come later. Sometimes there is a "reference implementation" and the documentation for that becomes, in effect, the standard. But once the process is in place, it is now the standard that defines the language, and future implementations are intended to conform to the standard. Implementations can have extensions and extra features, and those can strongly influence future versions of the standard, but the standard defines how the language works. Thus many features that were added to C and C++ after their initial standardisation began as extensions in compilers - especially gcc. But the standardised features were what the language committees felt were best for the language going forward - /not/ a codification of existing practice. There are countless examples of new features in language standards that are clearly inspired by, but noticeably different from, extensions in compilers.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c++
csiph-web