Re: mutex question

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, it's best not to encourage bad habits.

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.

Well, under the POSIX standard, volatile is useless for multithreading (only the synchronization primitives are allowed). Windows programming doesn't have a standard as such, nor have MS even gone to the effort of properly defining their memory model, but Itanium and Alpha do have weak cache coherency AFAIK. On those platforms, volatile is useless for multithreading. On other Windows platforms where volatile does work under some situations, I personally would not use it for multithreading, since the code is not portable, future proof or efficient.

[...]


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:

#include <windows.h>
#include <process.h>
#include <iostream>

unsigned __int64 const val1 = 0xFFFFFFFFll;
unsigned __int64 const val2 = 0xFFFFFFFF00000000ll;
volatile unsigned __int64 var = val1;

void checkVar()
{
unsigned __int64 value = var;
if (value != val1 && value != val2)
{
std::cout << "What, I'm wrong!? var had value: " << value << '\n';
exit(0);
}
}

void testVar()
{
while (1)
{
var = val1;
checkVar();
var = val2;
checkVar();
}
}

void tester(void* arg)
{
testVar();
}

int main()
{
_beginthread(tester, 0, NULL);
testVar();
}

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?

Tom
.

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)
Loading