thread safety of static initialization
Gilbert Chang
void foo(void) {
static int i = 0;
if (i == 0) {
i = 5;
}
assert(i == 5);
}
In a multi-threaded program, is it guranteed the assertion will always
be true?
Thanks,
Gilbert Chang
Neil Butterworth
"Gilbert Chang" <gcha...@attbi.com> wrote in message
news:3D799CC2...@attbi.com...
> Consider the following code:
>
> void foo(void) {
> static int i = 0;
> if (i == 0) {
> i = 5;
> }
> assert(i == 5);
> }
>
> In a multi-threaded program, is it guranteed the assertion will always
> be true?
>
Standard C++, the topic of this newsgroup, has nothing to say about
threading, so it is impossible to answer your question in that context.
NeilB
Alexander Terekhov
Neil Butterworth wrote:
>
> "Gilbert Chang" <gcha...@attbi.com> wrote in message
> news:3D799CC2...@attbi.com...
> > Consider the following code:
> >
> > void foo(void) {
> > static int i = 0;
> > if (i == 0) {
> > i = 5;
> > }
> > assert(i == 5);
> > }
> >
> > In a multi-threaded program, is it guranteed the assertion will always
> > be true?
No. static locals (and "memory locations") aside for a moment,
you should ALWAYS follow portable Memory Synchronization rules:
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_10
"Memory Synchronization
Applications shall ensure that access to any memory location by more
than one thread of control (threads or processes) is restricted such
that no thread of control can read or modify a memory location while
another thread of control may be modifying it. Such access is
restricted using functions that synchronize thread execution and
also synchronize memory with respect to other threads. The following
functions synchronize memory with respect to other threads:
<snip posix functions>
Unless explicitly stated otherwise, if one of the above functions
returns an error, it is unspecified whether the invocation causes
memory to be synchronized.
Applications may allow more than one thread of control to read
a memory location simultaneously."
> >
>
> Standard C++, the topic of this newsgroup,
Show me the charter, to begin with, my friend.
Here's one, just for your information, silly COP.
ftp://ftp.isc.org/pub/usenet/news.announce.newgroups/comp/comp.lang.c++.moderated
"....
comp.lang.c++.moderated is an moderated news group for discussion of
common C++ programming issues. Welcomed topics of discussion will
include any topic directly related to the C++ programming language.
The moderators will decide which posts are of general interest to the
worldwide C++ community.
...."
> has nothing to say about
> threading, so it is impossible to answer your question in that context.
regards,
alexander.
Xiaodong Huang
Quote from standard (draft): "A local object of POD type (3.9) with
static storage duration initialized with constant expressions is
initialized before its block is first entered.". So no matter what
context of thread in which foo is called, i is already initialized to
0. i could only be 0 or 5 in your case and the value change is always
one way, from 0 to 5. If i is 5 when foo is called in thread A, the
assertion holds (is true). If i is 0 when foo is called in thread B,
it will be changed to 5 and so the assertion holds, too.
Xiaodong Huang
Victor Bazarov
>
> Neil Butterworth wrote:
> > [...]
> >
> > Standard C++, the topic of this newsgroup,
>
> Show me the charter, to begin with, my friend.
There are two sources of information for you, if you haven't
seen them yet:
http://www.parashift.com/c++-faq-lite/how-to-post.html
http://www.slack.net/~shiva/welcome.txt
> Here's one, just for your information, silly COP.
> [...exerpt from comp.lang.c++.moderated announcement snipped...]
WTF does this have to do with comp.lang.c++? The two newsgroups
are only distantly related.
BTW, WTF is COP? Apparently, it's an abbreviation, since you
used all capital letters, but what is it the abbreviation for?
> > has nothing to say about
> > threading, so it is impossible to answer your question in that context.
>
>
http://groups.google.com/groups?as_q=thread%20safety%20of%20static%20initial
ization&safe&as_ugroup=comp.lang.c%2b%2b.moderated
Again, a link to a thread from a different newsgroup? Are you
lost, my little boy? Let me explain it to you: this newsgroup
is about the standard C++ language. Its standard say nothing
about threading. So, this newsgroup has nothing to do with
threading, and any discussion on threading is off-topic here.
You want to discuss threading, you go somewhere else, silly OT
proponent.
Victor
--
Please remove capital A's from my address when replying by mail
Gilbert Chang
Gilbert
Angelo Fraietta
Gilbert Chang wrote:
> I was looking for standard C++ rules that have implication on thread
> safety. Specifically, I wanted to understand how static locals are
> initialized. I believe my question is relevant for this news group.
>
I think the question is relevant to the group. He asks about the
initialisation of static local variables which is within the charter. He
has given a context that he is wishing to use them, being threading --
not within the charter, but he has used this to clarify the point in
time at which the static local is assigned.
Additionally the quote
>>>has nothing to say about
>>>threading, so it is impossible to answer your question in that context.
Why do we have the volatile keyword if multithreading, or multiple
threads of execution are not inferred?
--
Angelo Fraietta
PO Box 859
Hamilton NSW 2303
Home Page
http://www.users.bigpond.com/angelo_f/
There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)
Alexander Terekhov
Victor Bazarov wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote...
> >
> > Neil Butterworth wrote:
> > > [...]
> > >
> > > Standard C++, the topic of this newsgroup,
> >
> > Show me the charter, to begin with, my friend.
>
> There are two sources of information for you, if you haven't
> seen them yet:
>
> http://www.parashift.com/c++-faq-lite/how-to-post.html
> http://www.slack.net/~shiva/welcome.txt
Repeat: show me the charter; one more time: CHARTER.
> > Here's one, just for your information, silly COP.
> > [...exerpt from comp.lang.c++.moderated announcement snipped...]
>
> WTF does this have to do with comp.lang.c++? The two newsgroups
> are only distantly related.
Right. c++.moderated does have a charter and approved moderators vs
this (charter-less) one is "moderated"-in-public by you and Sir NeilB
primarily, and a couple of others with a lot of free time, etc.
> BTW, WTF is COP? Apparently, it's an abbreviation, since you
> used all capital letters, but what is it the abbreviation for?
Caps were used to add EMPHASIS. As for the rest, check out free
Thesaurus available at http://www.m-w.com, for example.
> http://groups.google.com/groups?as_q=thread%20safety%20of%20static%20initial
> ization&safe&as_ugroup=comp.lang.c%2b%2b.moderated
>
> Again, a link to a thread from a different newsgroup? Are you
> lost, my little boy?
Bazarov, I'm relatively "big" one, believe me.
> Let me explain it to you: this newsgroup is about the standard C++
> language. ....
Bullshit. This newsgroup was around long before "standard C++ language"
was born.
regards,
alexander.
Alexander Terekhov
Angelo Fraietta wrote:
[...]
> Why do we have the volatile keyword if multithreading, or multiple
> threads of execution are not inferred?
http://groups.google.com/groups?threadm=ajaqne%24n9u%241%40glue.ucr.edu
("Subject: concurrency-induced memory-access anomalies", comp.std.c)
regards,
alexander.
Alexander Terekhov
"fuck off my case" a.k.a. Victor Bazarov wrote:
>
> [...I don't want this to be archived...]
But I want. Corrected. http://groups.google.com/groups?selm=3CF23482.D784CCEA%40web.de
> "Alexander Terekhov" <tere...@web.de> wrote...
> > Victor Bazarov wrote:
> > > "Alexander Terekhov" <tere...@web.de> wrote...
> > > > Neil Butterworth wrote:
> > > > > [...]
> > > > >
> > > > > Standard C++, the topic of this newsgroup,
> > > >
> > > > Show me the charter, to begin with, my friend.
> > >
> > > There are two sources of information for you, if you haven't
> > > seen them yet:
> > >
> > > http://www.parashift.com/c++-faq-lite/how-to-post.html
> > > http://www.slack.net/~shiva/welcome.txt
> >
> > Repeat: show me the charter; one more time: CHARTER.
>
> Could you please repeat it a bit more? You're already starting
> to sound like a parrot, a very big stupid, stubborn parrot. I
> showed you the source of the information delineating the rules
> followed by most normal people in this newsgroup. If you don't
> want to follow them, you should find another venue.
Yeah, ``most normal people.''
> > > > Here's one, just for your information, silly COP.
> > > > [...exerpt from comp.lang.c++.moderated announcement snipped...]
> > >
> > > WTF does this have to do with comp.lang.c++? The two newsgroups
> > > are only distantly related.
> >
> > Right. c++.moderated does have a charter and approved moderators vs
> > this (charter-less) one is "moderated"-in-public by you and Sir NeilB
> > primarily, and a couple of others with a lot of free time, etc.
>
> Yes, we try keeping it on topic. If we didn't, it would soon
> become useless, drowning in Windows, Threading, Graphics, Hardware,
> and other unrelated to C++ inquiries.
Oh, yeah, that's really good example of your incredibly DEEP
thinking, my friend.
> > > BTW, WTF is COP? Apparently, it's an abbreviation, since you
> > > used all capital letters, but what is it the abbreviation for?
> >
> > Caps were used to add EMPHASIS. As for the rest, check out free
> > Thesaurus available at http://www.m-w.com, for example.
>
> Emphasis should be added some other way. Using all caps means
> SHOUTING on Usenet. You need to familiarise yourself with customs
> of the meduim you're using. Read RFC1855 (I trust you know where
> to find it) and related documents.
http://www.faqs.org/rfcs/rfc1855.html
("UPPER CASE LOOKS AS IF YOU'RE SHOUTING.")
http://groups.google.com/groups?selm=782ohi%24o373%40nntp.cig.mot.com
(Subject: Re: Do caps mean shouting?)
"....
The "Netiquette rule" about caps as shouting
refers to (most by example) to complete articles,
paragraphs, sentences, and clauses; and not so
much to individual words or terms or concepts.
IMHO, if there are people out there with the
impression that all caps ALWAYS means shouting,
then we need to let them know that is not the
case. But I don't think it would be right to
refrain from caps altogether because of folks
that had the misfortune of having only ever
seen them used for more inflammatory statements.
They serve many good non-inflammatory uses that
I would not be amenable to throwing out along
with the abuses.
...."
> http://groups.google.com/groups?as_q=thread%20safety%20of%20static%20initial
> > > ization&safe&as_ugroup=comp.lang.c%2b%2b.moderated
> > >
> > > Again, a link to a thread from a different newsgroup? Are you
> > > lost, my little boy?
> >
> > Bazarov, I'm relatively "big" one, believe me.
>
> Which means that you, Terekhov, are _still_ lost, big boy...
Uhmm, that's just yet another example of your ASTONISHINGLY DEEP
thinking, I guess.
> Oh well.
>
> > > Let me explain it to you: this newsgroup is about the standard C++
> > > language. ....
> >
> > Bullshit. This newsgroup was around long before "standard C++ language"
> > was born.
>
> So what? From the time the work started on standardising the
> language, by default, it became specialised in standard C++.
Oh, yeah, I see: comp.lang.c++.specialised.in.standard.c++ is
simply way too long (specialiSed vs specialiZed aside), I guess.
> If there _weren't_ any newsgroups related to some boundary topic,
> we could discuss the possibility to admit the topic here or to
> start another newsgroup. But since there is plenty of newsgroups
> on all the subject that are usually marked here as OT, what is your
> beef? Go there and be as much on topic as you wish.
Sorry, but I'll stay here.
> I am completely baffled by the fact that such a logical man like
> you, Terekhov, apparently very knowledgeable about C++, can continue
> to insist on being so stubborn and continue acting like a jackass.
Ha ha. Thanks for the compliments and really good laugh. ;-)
> You've been posting to this newsgroup for about half-a-year.
That's irrelevant.
> Have you not understood what keeps this newsgroup alive?
Frankly, I don't care much w.r.t. "what keeps this newsgroup alive".
> Here is a hint:
> it's not the presence of one or two highly qualified most valuable
> players, it's the togetherness of all the readers of the forum. If
> you want to act against the existing tradition, at least make your
> argument at the expected level, and stop throwing tantrums "show me
> the charter".
Thanks for the hint, Pioneer. Now, show me the charter, please.
> Of course, the logic suggests that what you do, you do out of spite,
> and not out of your convictions. Let me give you an advice: if you
> had a bad day, if your SO or XO gave you trouble, lay off Usenet
> for a while. It will save us some nerves, and, which is more
> important, it will save _you_ some nerves.
Well, I had really GOOD day (my last bad day was in Kindergarten,
IIRC) and, usually, I have no problems with respect to MY nerves
and Usenet; quite the opposite. (to tell the truth ;-) ;-) )
regards,
alexander.
Karl Heinz Buchegger
Alexander Terekhov wrote:
>
> > > Right. c++.moderated does have a charter and approved moderators vs
> > > this (charter-less) one is "moderated"-in-public by you and Sir NeilB
> > > primarily, and a couple of others with a lot of free time, etc.
> >
> > Yes, we try keeping it on topic. If we didn't, it would soon
> > become useless, drowning in Windows, Threading, Graphics, Hardware,
> > and other unrelated to C++ inquiries.
>
> Oh, yeah, that's really good example of your incredibly DEEP
> thinking, my friend.
Not really. It's just experience (they told me).
Years ago, on topicness wasn't considered a good thing to achieve.
There was a wild mix of questions and answers on any topic that was
at least somehow related to C++ (If anywhere in the world there lives
a person who's first name is C++, then asking for the health state of
his cousin's dog would have been on topic). The result: the newsgroup
was a wild mess, the *real* language experts went away and people not
really knowing what they are talking about answered newbies questions.
We don't want to fall back to that state.
[snip]
>
> Thanks for the hint, Pioneer. Now, show me the charter, please.
there is none. But Shivas welcome message as well as the FAQ serve
the same purpose: they define what is on topic and what is not. All
the regulars in this group agree on that. And we will not change this,
because you don't like it.
--
Karl Heinz Buchegger
kbuc...@gascad.at
Alexander Terekhov
Karl Heinz Buchegger wrote:
>
> Alexander Terekhov wrote:
> >
> > > > Right. c++.moderated does have a charter and approved moderators vs
> > > > this (charter-less) one is "moderated"-in-public by you and Sir NeilB
> > > > primarily, and a couple of others with a lot of free time, etc.
> > >
> > > Yes, we try keeping it on topic. If we didn't, it would soon
> > > become useless, drowning in Windows, Threading, Graphics, Hardware,
> > > and other unrelated to C++ inquiries.
> >
> > Oh, yeah, that's really good example of your incredibly DEEP
> > thinking, my friend.
>
> Not really. It's just experience (they told me).
> Years ago, on topicness wasn't considered a good thing to achieve.
> There was a wild mix of questions and answers on any topic that was
> at least somehow related to C++ (If anywhere in the world there lives
> a person who's first name is C++, then asking for the health state of
> his cousin's dog would have been on topic). The result: the newsgroup
AFAIK, "*real* language experts" (but not all) went to comp.lang.c++.
moderated. I guess, the problem was that due to lack of microsoft
specific newsgroups (comp.os.ms-windows.programmer.*{e.g. mfc}, etc.)
there was no other place to go for all those MS newbies and experts,
and, the way it was, it was working pretty well on comp.lang.c++ for
them. Blame Microsoft, but it's better now.
> > Thanks for the hint, Pioneer. Now, show me the charter, please.
>
> there is none. But Shivas welcome message as well as the FAQ serve
> the same purpose: they define what is on topic and what is not. All
> the regulars in this group agree on that. ....
Speak for yourself.
regards,
alexander.
White Wolf
Michael ;-)
See my comments below:
BTW, did you know that I have invented USENET flame-war? People before
that were just confused: they did not know where to show their overgrown
ego, where can they fight without being actually hit and so use up their
excess testosterone.
Alexander Terekhov wrote:
> Victor Bazarov wrote:
>
>>"Alexander Terekhov" <tere...@web.de> wrote...
>>
>>>Neil Butterworth wrote:
>>>
>>>>[...]
>>>>
>>>>Standard C++, the topic of this newsgroup,
>>>
>>>Show me the charter, to begin with, my friend.
>>
>>There are two sources of information for you, if you haven't
>>seen them yet:
>>
>>http://www.parashift.com/c++-faq-lite/how-to-post.html
>>http://www.slack.net/~shiva/welcome.txt
>
>
> Repeat: show me the charter; one more time: CHARTER.
Pick one:
http://www.charterauction.com/index.asp
http://www.un.org/aboutun/charter/
>>>Here's one, just for your information, silly COP.
>>>[...exerpt from comp.lang.c++.moderated announcement snipped...]
>>
>>WTF does this have to do with comp.lang.c++? The two newsgroups
>>are only distantly related.
>
>
> Right. c++.moderated does have a charter and approved moderators vs
> this (charter-less) one is "moderated"-in-public by you and Sir NeilB
> primarily, and a couple of others with a lot of free time, etc.
I don't have loads of free time but I love to send abuser of clc++ to
hell. Wanna try? ;-)
>>BTW, WTF is COP? Apparently, it's an abbreviation, since you
>>used all capital letters, but what is it the abbreviation for?
>
>
> Caps were used to add EMPHASIS. As for the rest, check out free
> Thesaurus available at http://www.m-w.com, for example.
NO. CAPS ARE USED FOR SHOUTING. HEAR? _This_ is epmhasis. Learn
netiquette before you teach it! :-)))
>>http://groups.google.com/groups?as_q=thread%20safety%20of%20static%20initial
>>ization&safe&as_ugroup=comp.lang.c%2b%2b.moderated
>>
>>Again, a link to a thread from a different newsgroup? Are you
>>lost, my little boy?
>
>
> Bazarov, I'm relatively "big" one, believe me.
Hey! Please read the welcome.txt! Penis envy is definitely forbidden
here! ;-)
>>Let me explain it to you: this newsgroup is about the standard C++
>>language. ....
>
> Bullshit. This newsgroup was around long before "standard C++ language"
> was born.
Ever read a Scott Meyers book? You can read about how ignorant and
arrogant people like ....elf screwed up this newsgroup. And then the
gurus sit together, and thus the PowerPuff Girl Were Born... I mean then
the moderated newsgroup was created so that dedicated abusers can just
be privately be executed. ;-)
I just love a good FIGHT. And sugar. It is just sad this is my last
time here! It is good to fight with you Alexander. You are just getting
better and better. I even start to forgive you those things in Egypt. :-)))
--
Michael a.k.a WW a.k.a Attila
Ps: Please doc, just few more minutes! No, I cannot type in a
straightjacket!
Alexander Terekhov
White Wolf wrote:
>
> FIGHT!
RIGHT!
[...]
> >>http://www.parashift.com/c++-faq-lite/how-to-post.html
> >>http://www.slack.net/~shiva/welcome.txt
> >
> > Repeat: show me the charter; one more time: CHARTER.
>
> Pick one:
>
> http://www.charterauction.com/index.asp
Ha! May I now have your username and password, please? ;-)
> http://www.un.org/aboutun/charter/
Oh, you should really email this one (and especially links to Chapters
VI and VII) to Mr. Bush Jr. ;-)
[...]
> > Right. c++.moderated does have a charter and approved moderators vs
> > this (charter-less) one is "moderated"-in-public by you and Sir NeilB
> > primarily, and a couple of others with a lot of free time, etc.
>
> I don't have loads of free time but I love to send abuser of clc++ to
> hell. Wanna try? ;-)
Well, some time ago (you and NeilB were totally busy sending yet another
newbie/abuser of clc++ to hell; exactly, yeah), I've already warned you:
http://groups.google.com/groups?threadm=3C7BC89B.226F2741%40web.de
(Subject: Re: newsgroup suggestion)
Okay, I'll try one more time: beware, given recently increased WW
population (and mostly due to leaked "Wolfed" movie stuff, see below),
there's a wolf killer hiding behind almost every cyber rock, WW. ;-)
[...]
> Michael a.k.a WW a.k.a Attila
Yeah, I see: upcoming "Wolfed" movie... Michael... Jackson finally
turning into big old nasty {sort of white; but pack leader no doubt}
wolf... Uhmm. Attila? .... Akela! (or something like that ;-) ;-) )
http://www.creature-corner.com/news2/may22wolfed.php3
("Terror has a new name. Terror has a new face.")
Attila Feher
>
> White Wolf wrote:
> >
> > FIGHT!
>
> RIGHT!
[SNIP]
> > http://www.charterauction.com/index.asp
>
> Ha! May I now have your username and password, please? ;-)
Sorry, Bill Gates stole it. :-(
> > http://www.un.org/aboutun/charter/
>
> Oh, you should really email this one (and especially links to Chapters
> VI and VII) to Mr. Bush Jr. ;-)
What was the address again? bus...@kindergarden.gov ?
> [...]
> > > Right. c++.moderated does have a charter and approved moderators vs
> > > this (charter-less) one is "moderated"-in-public by you and Sir NeilB
> > > primarily, and a couple of others with a lot of free time, etc.
> >
> > I don't have loads of free time but I love to send abuser of clc++ to
> > hell. Wanna try? ;-)
>
> Well, some time ago (you and NeilB were totally busy sending yet another
> newbie/abuser of clc++ to hell; exactly, yeah), I've already warned you:
>
> http://groups.google.com/groups?threadm=3C7BC89B.226F2741%40web.de
> (Subject: Re: newsgroup suggestion)
You have a loads of time on your handz...
> Okay, I'll try one more time: beware, given recently increased WW
> population (and mostly due to leaked "Wolfed" movie stuff, see below),
> there's a wolf killer hiding behind almost every cyber rock, WW. ;-)
White Wolfs don't care. The last Wolf killer died with severe injuries
resulted from uncontrollable laugh. So beware! ;-)
> [...]
> > Michael a.k.a WW a.k.a Attila
>
> Yeah, I see: upcoming "Wolfed" movie... Michael... Jackson finally
> turning into big old nasty {sort of white; but pack leader no doubt}
> wolf... Uhmm. Attila? .... Akela! (or something like that ;-) ;-) )
> http://www.creature-corner.com/news2/may22wolfed.php3
Not to mention Wolf-Einstein :-)
> ("Terror has a new name. Terror has a new face.")
Well, the new name is here. For the new face I need to go through some
precautory health checks first.
Attila a.k.a WW a.k.a the USENET thread unsafe reference counter COW
smart S
Neil Butterworth
news:3D7BFFEE...@xbigpond.com...
>
>
> Gilbert Chang wrote:
>
> > I was looking for standard C++ rules that have implication on thread
> > safety. Specifically, I wanted to understand how static locals are
> > initialized. I believe my question is relevant for this news group.
> >
>
> I think the question is relevant to the group. He asks about the
> initialisation of static local variables which is within the charter. He
> has given a context that he is wishing to use them, being threading --
> not within the charter, but he has used this to clarify the point in
> time at which the static local is assigned.
>
> Additionally the quote
> >>>has nothing to say about
> >>>threading, so it is impossible to answer your question in that
context.
>
> Why do we have the volatile keyword if multithreading, or multiple
> threads of execution are not inferred?
The C++ standard has nothing to say about the volatile keyword in the
context of multi-threading.
NeilB
Geoff Field
news:3d7e4f88$1...@mk-nntp-1.news.uk.worldonline.com...[snip]
> > Why do we have the volatile keyword if multithreading, or multiple
> > threads of execution are not inferred?
>
> The C++ standard has nothing to say about the volatile keyword in the
> context of multi-threading.
Further to NeilB's comments, volatile is commonly used on non-hosted
(ie, embedded) platforms in particular for things like memory-mapped
peripherals and variables/flags that may be changed by interrupt
service routines.
It's sometimes used on hosted systems for similar purposes, as well.
The fact that it's also useful for multi-threaded applications is a bonus.
Geoff
--
Geoff Field, Professional geek, amateur stage-levelling gauge.
Spamtraps: geoff...@suespammers.org, geoff...@hotmail.com or
geoff...@great-atuin.co.uk; Real Email: gcfield at optusnet dot com dot
au
The suespammers.org mail server is located in California; do not send
unsolicited bulk or commercial e-mail to my suespammers.org address
Angelo Fraietta
"Geoff Field" <geoff...@suespammers.org> wrote in message
news:10317097...@cswreg.cos.agilent.com...
> "Neil Butterworth" <neil_but...@lineone.net> wrote in message
> news:3d7e4f88$1...@mk-nntp-1.news.uk.worldonline.com...
> > "Angelo Fraietta" <ange...@xbigpond.com> wrote in message
> > news:3D7BFFEE...@xbigpond.com...
> [snip]
> > > Why do we have the volatile keyword if multithreading, or multiple
> > > threads of execution are not inferred?
> >
> > The C++ standard has nothing to say about the volatile keyword in the
> > context of multi-threading.
>
> Further to NeilB's comments, volatile is commonly used on non-hosted
> (ie, embedded) platforms in particular for things like memory-mapped
> peripherals and variables/flags that may be changed by interrupt
> service routines.
>
> It's sometimes used on hosted systems for similar purposes, as well.
>
> The fact that it's also useful for multi-threaded applications is a bonus.
>
> Geoff
>
>
http://groups.google.com/groups?threadm=ajaqne%24n9u%241%40glue.ucr.edu
It states
There are four memory-access anomalies that arise in environments
where multiple concurrent streams of computational activity share
access to a given object or collection of objects. Those streams may
be threads and/or the handling signals, interrupts, exceptions, or
longjmps.
My understanding of this is that ISR fit into the area of
multiple concurrent streams of computational activity
Geoff Field
news:hVxf9.18837$_l1....@news-server.bigpond.net.au...
Yes, but they're not threads. Note the wording of the last sentence.
OTOH, I just noted the wording of the first of your sentences that I
quoted four or so posts back. It looks like NeilB may have jumped
on the "multithreading" part without noticing the rest of it - as did I.
Personally, IME there are *very few* computer systems that do not
rely to a greater or lesser extent on multiple concurrent streams of
activity, even if they're just looping waiting for an interrupt to happen.
I *have* worked on some very small and simple embedded systems
that simply polled the inputs, but the majority of my projects over the
years have involved some sort of interrupt capability. Some were even
written in HLLs...
Attila Feher
[SNIP]
> The C++ standard has nothing to say about the volatile keyword in the
> context of multi-threading.
Whadda looser this standard is. Andrei Alexandrescu does have something
(well, sth pretty cool) to say about volatile and threading. Something
so cool, it would be even on-topic.
Just a sidebar-comment: as long as the topic stays at
non-platform/implementation-specific matters I believe that as Andrei
has not been kicked out that: "this is not a Standard C++ article"
(because in fact it was one) people here should also be a bit more
practical and _not_ run to kill every post which is not "a quote from
the standard".
There are _practical_ everyday uses of C++ and that includes threading.
While platform/implementation specific means of achieving threading and
related functionality is definitely off-topic here the use of C++
language features to support writing MT code should be on-topic.
IMHO,
Attila
Joe Clarke
Attila Feher wrote:
I agree -- so long as it is not platform specific.
Alexander Terekhov
Geoff Field wrote:
[...C/C++ volatiles/memory-mapped-IO/signals...]
> The fact that it's also useful for multi-threaded applications is a bonus.
The "fact" that it's "also useful" for multi-threaded applications is a *bug*
(rather popular [it's even mentioned in standard C Rationale] *misconception*)
regards,
alexander.
Alexander Terekhov
Attila Feher wrote:
[...]
> Whadda looser this standard is. Andrei Alexandrescu does have something
> (well, sth pretty cool) to say about volatile and threading. Something
> so cool, it would be even on-topic.
Andrei... about *volatile an threading*? "so cool"? Forget it!
http://groups.google.com/groups?selm=3D662CEB.BD172CCA%40web.de
(Subject: Re: stl deques and "volatile")
regards,
alexander.
Attila Feher
I dunno where do you get your self esteem, but it should be cheap and
plenty there.
A
Alexander Terekhov
Why do you think so ("self esteem")?
regards,
alexander.
Attila Feher
I KNOW! Spelling. So what? :-)
I meant no offense, but you are not low on self whatever. I mean you
can so easily state stuff (with no short and understandable reasoning
but with links to stuff not always seem to contain reasoning acceptable
for me. I have quit to follow them for the last 12 hours) and with so
high self confidence... One might think that The Creator Him(Her?)Self
posts here using an alias. :-)
A
Alexander Terekhov
Attila Feher wrote:
>
> Alexander Terekhov wrote:
[...Andrei Alexandrescu/volatiles and threading -> link...]
> > > I dunno where do you get your self esteem, ...
> >
> > Why do you think so ("self esteem")?
>
> I KNOW! Spelling. So what? :-)
>
> I meant no offense,
^^^^^^^
What's this? ;-)
> but you are not low on self whatever.
I need to know why do you think so.
> I mean you can so easily state stuff (with no short and understandable
> reasoning but with links to stuff not always seem to contain reasoning
> acceptable for me.
Acceptable? Or, perhaps, understandable? If so, why not simply ask for
clarification or just ignore?
> I have quit to follow them for the last 12 hours)
That's okay.
> and with so high self confidence... One might think that The Creator
> Him(Her?)Self posts here using an alias. :-)
One might think whatever s/he wants. That's not my problem (I'm just
curious with respect to this particular case engaging you), I believe.
regards,
alexander.
Neil Butterworth
"Attila Feher" <Attila...@lmf.ericsson.se> wrote in message
news:3D7EC741...@lmf.ericsson.se...
> Neil Butterworth wrote:
> [SNIP]
> > The C++ standard has nothing to say about the volatile keyword in the
> > context of multi-threading.
>
> Whadda looser this standard is. Andrei Alexandrescu does have something
> (well, sth pretty cool) to say about volatile and threading. Something
> so cool, it would be even on-topic.
So cool that it is in fact wrong.
NeilB
Attila Feher
[SNIP]
> > I meant no offense,
> ^^^^^^^
>
> What's this? ;-)
What Bush Jr. is doing nowadays in foreign politics?
> > but you are not low on self whatever.
>
> I need to know why do you think so.
Well, since I am no shrink I just can say this is my observation.
Nothing wrong with it. :-)
> > I mean you can so easily state stuff (with no short and understandable
> > reasoning but with links to stuff not always seem to contain reasoning
> > acceptable for me.
>
> Acceptable? Or, perhaps, understandable? If so, why not simply ask for
> clarification or just ignore?
I have selected ignore. The reaosn is political: it still look like
someone who understood. :-)
> > I have quit to follow them for the last 12 hours)
>
> That's okay.
Thx ;-)
> > and with so high self confidence... One might think that The Creator
> > Him(Her?)Self posts here using an alias. :-)
>
> One might think whatever s/he wants.
Usually even if you try to change that it doesn't work. The only place
where it does exists in Orwell's mind. :-)
> That's not my problem
Well... No I take the chance to offend you by mistake, but: if you act
like a smartass and people (people who are very kind and tolerant)
happen to put you into their killfile for that... well at some point
itmay be a problem for you.
> (I'm just curious with respect to this
> particular case engaging you), I believe.
I know Andrei and I know you. And I can understand that you have some
sort of opinion about what he did/said at a particular moment in time...
I just has the feeling that the "absolute truth" way you have expressed
you opinion can easily make people detect an annoying level of self
confidence and it may even be detected as a sort of arrogance.
And if I don't do lawyer talk I could say that: I am sure that you can
make these statement in a less hurtful/offending tone. Well, I could
explain this much better in Hungarian, but then you would not understand
it. :-)
Attila
Attila Feher
Not according what I have understood. But I just love when people post
statements (opinions) with no technical facts to back it up.
Attila
Neil Butterworth
Read the newsgroup posts that Terekhov cited. This has been discussed here
numerous times.
NeilB
Attila Feher
[SNIP]
> > Not according what I have understood. But I just love when people post
> > statements (opinions) with no technical facts to back it up.
>
> Read the newsgroup posts that Terekhov cited. This has been discussed here
> numerous times.
I have read it. I don't see why would that talk by Terekhov prove that
Andrei's idea is plain wrong. I really did read it just now, all
through and it is just slipping of the topic. I do not remember Andrei
claiming that his idiom would solve all possible race conditions and
conflicts neither did I understand from the original article that he has
assumed that volatile will provide sufficient full synchronization. I
may have been careless when reading it - I still do not believe that
what he wrote is all plain wrong.
Attila
Alexander Terekhov
Attila Feher wrote:
>
> Alexander Terekhov wrote:
> [SNIP]
> > > I meant no offense,
> > ^^^^^^^
> >
> > What's this? ;-)
>
> What Bush Jr. is doing nowadays in foreign politics?
He's helping oil and gold prices make higher ground, to begin with.
[...that's not my problem...]
> Well... No I take the chance to offend you by mistake, but: if you act
> like a smartass and people (people who are very kind and tolerant)
> happen to put you into their killfile for that... well at some point
> itmay be a problem for you.
Well, sure, I'll never be bothered by a reply from such "very kind
and tolerant" person again, but how the heck "it may be a problem"
for me at some point?
> > (I'm just curious with respect to this
> > particular case engaging you), I believe.
>
> I know Andrei and I know you.
You know me? I don't think so. ;-)
> And I can understand that you have some
> sort of opinion about what he did/said at a particular moment in time...
> I just has the feeling that the "absolute truth" way you have expressed
> you opinion can easily make people detect an annoying level of self
> confidence and it may even be detected as a sort of arrogance.
So be it.
regards,
alexander.
Alexander Terekhov
Attila Feher wrote:
>
> Neil Butterworth wrote:
> [SNIP]
> > > Not according what I have understood. But I just love when people post
> > > statements (opinions) with no technical facts to back it up.
> >
> > Read the newsgroup posts that Terekhov cited. This has been discussed here
> > numerous times.
>
> I have read it. I don't see why would that talk by Terekhov
Attila, I don't give talks (I'm not in this business); Andrei does.
The "newsgroup posts that Terekhov cited" were written by a) Aleksey
Gurtovoy (booster/MPL/etc.) and b) David Butenhof ("POSIX Thread
Architect"/etc.).
> prove that
> Andrei's idea is plain wrong. I really did read it just now, all
Really?
> through and it is just slipping of the topic. I do not remember Andrei
> claiming that his idiom would solve all possible race conditions and
> conflicts neither did I understand from the original article that he has
> assumed that volatile will provide sufficient full synchronization. ...
Really? The general problem of casting away volatility aside,
follow the link: http://www.cuj.com/experts/1902/alexandr.htm
"....
Although both C and C++ Standards are conspicuously silent when it
comes to threads, they do make a little concession to multithreading,
in the form of the volatile keyword. "
That's wrong.
"Just like its better-known counterpart const, volatile is a type
modifier. It's intended to be used in conjunction with variables that
are accessed and modified in different threads. "
That's wrong.
"Basically, without volatile, either writing multithreaded programs
becomes impossible, or the compiler wastes vast optimization
opportunities. "
That's wrong.
"An explanation is in order.
<snip>
So all you have to do to make Gadget's Wait/Wakeup combo work is to
qualify flag_ appropriately:
class Gadget
{
public:
... as above ...
private:
volatile bool flag_;
}; "
That's wrong.
"Most explanations of the rationale and usage of volatile stop here
and advise you to volatile-qualify the primitive types that you use
in multiple threads. "
Well, that's also kinda wrong.
Enough, Attila?
regards,
alexander.
Attila Feher
[SNIP]
> > What Bush Jr. is doing nowadays in foreign politics?
>
> He's helping oil and gold prices make higher ground, to begin with.
>
> [...that's not my problem...]
When they will get to the beer prices! :-)
> Well, sure, I'll never be bothered by a reply from such "very kind
> and tolerant" person again, but how the heck "it may be a problem"
> for me at some point?
That is too much philosophy now, but you even if you do not make friend
you certainly do not want to alienate people.
> > > (I'm just curious with respect to this
> > > particular case engaging you), I believe.
> >
> > I know Andrei and I know you.
>
> You know me? I don't think so. ;-)
Usenet wise :-)
> > And I can understand that you have some
> > sort of opinion about what he did/said at a particular moment in time...
> > I just has the feeling that the "absolute truth" way you have expressed
> > you opinion can easily make people detect an annoying level of self
> > confidence and it may even be detected as a sort of arrogance.
>
> So be it.
Ledidbeeee...
A
White Wolf
> Attila Feher wrote:
>
> Attila, I don't give talks (I'm not in this business); Andrei does.
I see you start to pick on everything...
> The "newsgroup posts that Terekhov cited" were written by a) Aleksey
> Gurtovoy (booster/MPL/etc.) and b) David Butenhof ("POSIX Thread
> Architect"/etc.).
And?
>>prove that
>>Andrei's idea is plain wrong. I really did read it just now, all
>
> Really?
Reallyy. I have read the posts at the other end of the link you gave.
>>through and it is just slipping of the topic. I do not remember Andrei
>>claiming that his idiom would solve all possible race conditions and
>>conflicts neither did I understand from the original article that he has
>>assumed that volatile will provide sufficient full synchronization. ...
>
>
> Really? The general problem of casting away volatility aside,
> follow the link: http://www.cuj.com/experts/1902/alexandr.htm
>
> "....
> Although both C and C++ Standards are conspicuously silent when it
> comes to threads, they do make a little concession to multithreading,
> in the form of the volatile keyword. "
>
> That's wrong.
No, this isn't wrong.
> "Just like its better-known counterpart const, volatile is a type
> modifier. It's intended to be used in conjunction with variables that
> are accessed and modified in different threads. "
>
> That's wrong.
So far it sin't wrong.
> "Basically, without volatile, either writing multithreaded programs
> becomes impossible, or the compiler wastes vast optimization
> opportunities. "
>
> That's wrong.
No, it isn't wrong. Andrei means that if there was no "volatile
warning" for the compiler it should treat _all_ (non-automatic)
variables as volatile ones, therefore could not optimize.
> "An explanation is in order.
>
> <snip>
>
> So all you have to do to make Gadget's Wait/Wakeup combo work is to
> qualify flag_ appropriately:
>
> class Gadget
> {
> public:
> ... as above ...
> private:
> volatile bool flag_;
> }; "
>
> That's wrong.
That _is_ wrong. bool has to be sig_atomic_t to work - as long as only
assignment and read is done. (Only those are atomic on sig_atomic_t.)
> "Most explanations of the rationale and usage of volatile stop here
> and advise you to volatile-qualify the primitive types that you use
> in multiple threads. "
>
> Well, that's also kinda wrong.
Yep. Volatile does not make a variable thread safe - however without
volatile you may see interesting things _even_ if the variable is atomic.
> Enough, Attila?
Yes. It is way too important for you (today) to be right - so you flag
everything wrong, even those which aren't completely and even if it
takes a deliberate misunderstanding of a clear text.
So since it is so important for you: you are right. I am tired of this
endless ego-show. It is like discussing with Dave Pearson on
c.l.clipper on a bad day of his.
Attila
Alexander Terekhov
White Wolf wrote:
[...]
> > "An explanation is in order.
> >
> > <snip>
> >
> > So all you have to do to make Gadget's Wait/Wakeup combo work is to
> > qualify flag_ appropriately:
> >
> > class Gadget
> > {
> > public:
> > ... as above ...
> > private:
> > volatile bool flag_;
> > }; "
> >
> > That's wrong.
>
> That _is_ wrong. bool has to be sig_atomic_t to work - as long as only
> assignment and read is done. (Only those are atomic on sig_atomic_t.)
http://groups.google.com/groups?threadm=3D4A8DDD.5A935D95%40web.de
(Subject: Re: "memory location")
regards,
alexander.
--
"FIGHT!" -WW
Attila Feher
[SNIP]
> > That _is_ wrong. bool has to be sig_atomic_t to work - as long as only
> > assignment and read is done. (Only those are atomic on sig_atomic_t.)
>
> http://groups.google.com/groups?threadm=3D4A8DDD.5A935D95%40web.de
> (Subject: Re: "memory location")
OK. Now I am puzzled. So far I was assured by several, that
sig_atomic_t is "the stuff" which is A OK and safe to write from one
thread and read from the other. I mean Thread A _only_ writes (OK,
maybe reads but what for) and Thread B _only_ reads. Do you mean that
this doesn't work?
Attila
Alexander Terekhov
Yes. And even if it WOULD work (i.e. atomicity), you I'd still have
the problem of visibility w.r.t. dependent {mutable} data (if any).
regards,
alexander.
White Wolf
Now I am even more puzzled: why is it called sig_atomic_t if it isn't?
Why do "big old names" say it _is_ safe to use it (well, from interrupt
routines, but in an MT environment that IT can come whoknowswhatway).
So one thing. If read and write _is_ atomic for this type, what is the
problem? AFAIK (OK, did not read it) the standard asks for it. Then
why cannot I use for (for example) a dirty flag? I look at my copy of
sth (reading this flag) and if it is non-zero (integral type it is) then
I know I have (when I want) update my copy. Which will certainly
involve some sort of locking - again if needed. Got it? Why cannot I
use this type in MT enviroment for this? One threads writes (only!) the
data, others may read it. Where can it go wrong? Please do not post
links to scattered lengthy discussion - I am a simple man and I get
confused easily.
I have worked in Intel (OK, only 8086) assembly, still have the books
about Z80 and some more HW design so let's cut to the chase! What does
make sig_atomic_t non-safe. I do not care about POSIX, that is
something what is made by pretty clever in a way that I will not
understand (standard). However I understand the concept of system bus,
somewhat the cache (cash even moe :-), controll signals and the like.
So where the heck can it go wrong, if the operation is atomic?
--
WW a.k.a Attila
Alexander Terekhov
White Wolf wrote:
>
> Alexander Terekhov wrote:
> > Attila Feher wrote:
> >
> >>Alexander Terekhov wrote:
> >>[SNIP]
> >>
> >>>>That _is_ wrong. bool has to be sig_atomic_t to work - as long as only
> >>>>assignment and read is done. (Only those are atomic on sig_atomic_t.)
> >>>
> >>>http://groups.google.com/groups?threadm=3D4A8DDD.5A935D95%40web.de
> >>>(Subject: Re: "memory location")
> >>
> >>OK. Now I am puzzled. So far I was assured by several, that
> >>sig_atomic_t is "the stuff" which is A OK and safe to write from one
> >>thread and read from the other. I mean Thread A _only_ writes (OK,
> >>maybe reads but what for) and Thread B _only_ reads. Do you mean that
> >>this doesn't work?
> >
> >
> > Yes. And even if it WOULD work (i.e. atomicity), you I'd still have
> > the problem of visibility w.r.t. dependent {mutable} data (if any).
>
> Now I am even more puzzled: why is it called sig_atomic_t if it isn't?
It (i.e. *static volatile sig_atomic_t*) IS "atomic" (and even
thread-safe ;-) ) with respect to ONE SINGLE thread that reads
and writes it AND signal handler(s) "interrupting" THAT thread.
IOW, it has really nothing to do with threads.
http://www.lysator.liu.se/c/rat/b.html#2-2-3
("2.2.3 Signals and interrupts", ANSI C89 Rationale)
> Why do "big old names" say it _is_ safe to use it (well, from interrupt
> routines, but in an MT environment that IT can come whoknowswhatway).
>
> So one thing. If read and write _is_ atomic for this type, what is the
> problem? AFAIK (OK, did not read it) the standard asks for it. Then
> why cannot I use for (for example) a dirty flag? I look at my copy of
> sth (reading this flag) and if it is non-zero (integral type it is) then
> I know I have (when I want) update my copy. Which will certainly
> involve some sort of locking - again if needed. Got it? Why cannot I
> use this type in MT enviroment for this? One threads writes (only!) the
> data, others may read it. Where can it go wrong? Please do not post
> links to scattered lengthy discussion - I am a simple man and I get
> confused easily.
>
> I have worked in Intel (OK, only 8086) assembly, still have the books
> about Z80 and some more HW design so let's cut to the chase! What does
> make sig_atomic_t non-safe. I do not care about POSIX, that is
> something what is made by pretty clever in a way that I will not
> understand (standard). However I understand the concept of system bus,
> somewhat the cache (cash even moe :-), controll signals and the like.
> So where the heck can it go wrong, if the operation is atomic?
http://rsim.cs.uiuc.edu/~sadve/Publications/models_tutorial.ps
"5.2.1 Cache Coherence and Sequential Consistency
Several definitions for cache coherence (also referred to
as cache consistency) exist in the literature. The strongest
definitions treat the term virtually as a synonym for
sequential consistency. Other definitions impose
extremely relaxed ordering guarantees.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What does the programmer expect from the memory system to
ensure correct execution of this program fragment? One
important requirement is that the value read from the
data field within a dequeued record should be the same
as that written by P1 in that record. However, in many
commercial shared memory systems, it is possible for
processors to observe the old value of the data field
(i.e., the value prior to P1's write of the field),
leading to behavior different from the programmer's
expectations.
http://groups.google.com/groups?selm=c29b5e33.0202150632.6d579f24%40posting.google.com
(Subject: Re: Can multiple threads set a global variable simultaneously?)
regards,
alexander.
--
POSIX
"Applications shall ensure that access to any memory
location by more than one thread of control (threads
or processes) is restricted such that no thread of
control can read or modify a memory location while
another thread of control may be modifying it. Such
access is restricted using functions that synchronize
thread execution and also synchronize memory with
respect to other threads."
JAVA (revised Java volatiles aside)
"If two threads access a normal variable, and one
of those accesses is a write, then the program should
be synchronized so that the first access is visible to
the second access. When a thread T 1 acquires a lock
on/enters a monitor m that was previously held by
another thread T 2, all actions that were visible to
T 2 at the time it released the lock on m become
visible to T 1"
Attila Feher
[SNIP]
> > > Yes. And even if it WOULD work (i.e. atomicity), you I'd still have
> > > the problem of visibility w.r.t. dependent {mutable} data (if any).
> >
> > Now I am even more puzzled: why is it called sig_atomic_t if it isn't?
>
> It (i.e. *static volatile sig_atomic_t*) IS "atomic" (and even
> thread-safe ;-) ) with respect to ONE SINGLE thread that reads
> and writes it AND signal handler(s) "interrupting" THAT thread.
> IOW, it has really nothing to do with threads.
>
> http://www.lysator.liu.se/c/rat/b.html#2-2-3
> ("2.2.3 Signals and interrupts", ANSI C89 Rationale)
Hm. I re-learn something every day. Is it possible, that the Earth
isn't flat either? :-))
[SNIP]
> http://rsim.cs.uiuc.edu/~sadve/Publications/models_tutorial.ps
>
> "5.2.1 Cache Coherence and Sequential Consistency
> Several definitions for cache coherence (also referred to
> as cache consistency) exist in the literature. The strongest
> definitions treat the term virtually as a synonym for
> sequential consistency. Other definitions impose
> extremely relaxed ordering guarantees.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> What does the programmer expect from the memory system to
> ensure correct execution of this program fragment? One
> important requirement is that the value read from the
> data field within a dequeued record should be the same
> as that written by P1 in that record. However, in many
> commercial shared memory systems, it is possible for
> processors to observe the old value of the data field
> (i.e., the value prior to P1's write of the field),
> leading to behavior different from the programmer's
> expectations.
Do you mean that systems out there can actually show 32 different values
for variable X if they have 32 different CPUs? What sense does this
make? Is this some sort of lazyness or an "optimization"?
> --
> POSIX
>
> "Applications shall ensure that access to any memory
> location by more than one thread of control (threads
> or processes) is restricted such that no thread of
> control can read or modify a memory location while
> another thread of control may be modifying it. Such
> access is restricted using functions that synchronize
> thread execution and also synchronize memory with
> respect to other threads."
Ajve. And what happens if it does? I will see the old value?
> JAVA (revised Java volatiles aside)
>
> "If two threads access a normal variable, and one
> of those accesses is a write, then the program should
> be synchronized so that the first access is visible to
> the second access. When a thread T 1 acquires a lock
> on/enters a monitor m that was previously held by
> another thread T 2, all actions that were visible to
> T 2 at the time it released the lock on m become
> visible to T 1"
Nice. HOW? You mean that the operating systems starts to emulate the
CPU after a lock? Or in POSIX unlock the OS asks for cache refresh of
all CPUs for those very addresses changed? But what if those changes
"went out of the cache" into the main memory (many megabytes changed).
How will it remember what addresses did it change and what cache lines
should be invalidated in other CPUs? Or will it just ask for a full
cache update? I doubt that, it would be remarkably slow.
Attila