Re: mutex question

Slava M. Usov wrote:
"Tom Widmer [VC++ MVP]" <tom_usenet@xxxxxxxxxxx> wrote in message
news:uASK2TBeGHA.1856@xxxxxxxxxxxxxxxxxxxxxxx

Slava M. Usov wrote:

"Tom Widmer" <tom_usenet@xxxxxxxxxxx> wrote in message
news:%2333sd$AdGHA.4224@xxxxxxxxxxxxxxxxxxxxxxx

Yes. What's your definition of "sufficient" in the context of this
thread?


Something is sufficient for externally observable reads and writes when
externally observable reads and writes happen. Atomicity is completely
and
entirely irrelevant here.

We weren't talking about 'sufficient for externally observable reads and
writes'. Go back to the first usage of the term in this thread.


When I used this term, I knew what I was talking about. Do not attribute
your confusion to me.

Do you agree or disagree with my usage of sufficient, which has nothing much to do with your 'sufficient for externally observable reads and writes', by which I think you mean "triggers a memory read or write", without placing much in the way of semantics on those reads and writes.

My usage was:
'On the contrary, it is *not* necessary nor is it sufficient to use volatile on variables shared between threads.'

Here, the term 'sufficient' has some semantics attached to it with regard to the values of those shared variables.

That program didn't do anything useful.


Ignoratio elenchi.

Indeed - the example wasn't relevant to what you wanted it to prove,
though I accept that you might be able to modify it so that it is.


It was not my example and I did not try to prove anything. You're trying to
prove that 'volatile' is not what the language standard says it is, and the
example is very relevant because it is incompatible with your claims.

The program is non-standard - any multithreaded program is outside the C++ standard. What's the C++ standard definition of volatile got to do with its utility in multithreaded programming? You have to go outside the standard to individual compiler and platform behaviour, where (if you are lucky), the documentation details the multithreaded memory model in operation. For MS, this stuff is generally spread through the documentation of Interlocked*, _*Barrier and the synchronization primitives, though in many cases it leaves you to try to reason about the semantics based on its semantics in a single threaded program, or doesn't define them at all.

Introducing write and read barriers hardly makes things more efficient.

You're right in this case - efficiency is probably unaffected.

This is all you really need to say.

Indeed, I can admit when I'm wrong on a point. I hope this thread is still presenting some light on the issue to anyone still reading it.

Tom
.

Relevant Pages

  • Re: Use of volatile const
    ... because without the "volatile" the semantics ... It is unfortunate that the standard ... was phrased in terms of "may be modified by ghosts" instead of "must ...
    (comp.std.c)
  • Re: Is C99 the final C? (some suggestions)
    ... This would violate the division between preprocessor and compiler too ... much (the preprocessor would have to understand quite a lot of C semantics). ... ...This is legal C (as per the Standard), but it overflows the stack on ...
    (comp.lang.c)
  • 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: Countable models of ZFC
    ... When I say "M is a set", I don't mean it's a set living in some model, ... If so, WHAT IS THE DEFINITION (of standard, ... the WHOLE of first-order semantics with it. ... you'd best at LEAST concede that M was a proper class. ...
    (sci.logic)
  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... What the committee intended for both USAGE PACKED-DECIMAL is ... "178) USAGE PACKED-DECIMAL clause (computer storage allocation, ... even-number of digit, data items. ... It is my belief that the Standard INTENDED to consider both "conforming". ...
    (comp.lang.cobol)