Re: mutex question

"Tom Widmer [VC++ MVP]" <tom_usenet@xxxxxxxxxxx> wrote in message
news:O9o$NkpcGHA.3856@xxxxxxxxxxxxxxxxxxxxxxx
Slava M. Usov wrote:
"Tom Widmer [VC++ MVP]" <tom_usenet@xxxxxxxxxxx> wrote in message
news:uGzVlhEcGHA.3900@xxxxxxxxxxxxxxxxxxxxxxx

[...]


I didn't think we were talking about the C++ standard, but about the
utility of the volatile keyword.


You disputed somebody else's statements "about the utility of the
volatile keyword". The statements you disputed had been confirmed
experimentally.

While the OPs code may work in that simple situation

The code of the OP would not work in any situation.

it's best not to encourage bad habits.

The OP did not mention 'volatile' at all, so I am not even sure what you're
trying to discourage now. Anyway, trying to redefine 'volatile', as you did,
strikes me as a rather strange way of discouraging.

That can be disputed only with an assumption that the implementation of
the language was non-conformant with the standard. Non-conformance with a
standard cannot be demonstrated if the standard is not cited.

[...]

the POSIX standard

Very relevant and equally convincing.

[...]

Volatile is sufficient for any reads and writes. This is its entire and
only purpose.

Any reads and writes of what in what context? Are you talking about
multithreading now (the main topic of this thread) or about the standard
C++ abstract machine (which is of course single threaded, and therefore
off-topic)?


I do not need any context to talk about the sufficiency of a volatile
qualifier for reads and writes. Whatever the context, reads and writes to
a volatile object are guaranteed to happen.

They aren't:

[...]

The code that I just skipped does not support your statement; but it is in
perfect agreement with my statements.

It's not clear to me whether you are being pedantic or whether you don't
understand the issues WRT volatile and multiCPU (or even single CPU as
above). Which is it?

I am being unsupportive of your attempts to redefine 'volatile' and to
condemn its usage just because it needs a bit of thinking.

S


.

Relevant Pages

  • Re: Volatile in C99
    ... I realize that's your opinion; ... Yes as it is your opinion not everyone's that an access to volatile ... referred to several different sections of the Standard, ... unknown side-effects may be. ...
    (comp.std.c)
  • Re: Volatile in C99
    ... written so as not to need volatile for such cases. ... but saying setjmpcan be used in a strictly conforming ... fact solely by the text of the standard, which is the reason I said ... the wording should be clarified. ...
    (comp.std.c)
  • Re: Volatile in C99
    ... written so as not to need volatile for such cases. ... but saying setjmpcan be used in a strictly conforming ... the wording should be clarified. ... it isn't clear what possibilities the Standard "provides". ...
    (comp.std.c)
  • Re: Use of volatile const
    ... There's no reasonable way for that to happen, but the standard only ... It simply says "volatile qualified". ... int main ... the last store need not be explicit in the program." ...
    (comp.std.c)
  • Re: shared memory between processes
    ... >> that volatile was not required if you used mutexes, that standard would ... not the memory location? ... from making optimizations that interfere with multi-threaded code. ...
    (comp.os.linux.development.system)