Re: mutex question

Slava M. Usov wrote:
"Tom Widmer [VC++ MVP]" <tom_usenet@xxxxxxxxxxx> wrote in message
news:O9o$NkpcGHA.3856@xxxxxxxxxxxxxxxxxxxxxxx
While the OPs code may work in that simple situation
The code of the OP would not work in any situation.

Apologies - I meant "Stealer"'s code with volatile added to continue_flag.

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.

Well, I don't think I did attempt to define volatile:
This is why the 'volatile' keyword exists -- to tell the compiler
that a variable can change unexpectedly, such as when it is shared
between threads. Today's compilers are smart, but they can't read
your mind (yet). :)


That is *not* what volatile is for - multithreading is not part of its utility, rather hardware interaction is.

That doesn't look like a definition to me. There are two parts to my statement.
1. volatile is not useful for multithreading.
That was overstating the case slightly (to combat the hoardes of programmers who use it in a non-portable or incorrect manner for multithreading), but it is useless in that better alternatives exist (at least in the latest APIs).
2. volatile is useful for hardware interaction.
Do you disagree with this?

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

Your statements:
On certain platforms, volatile is perfectly sufficient [for variables shared between threads]. Incidentally, one of
these platforms is a de facto standard for win32.

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

My code demonstated the value of a shared volatile 64-bit variable becoming corrupt (on Win32, single CPU) when being read and written.

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

I haven't presented a definition of volatile. I am condemning its usage though, because it is neither necessary (ever for multithreading on Windows) nor sufficient (except in a few special cases). Can your present some VC8 compatible code using volatile for shared access of a variable between threads where _ReadBarrier, _WriteBarrier and Interlocked* wouldn't be more portable to other Windows platforms (and at least as performant, if not more so)?

Tom
.

Relevant Pages

  • Re: mutex question
    ... The 'volatile' keyword is useful with or without multithreading. ... and the very idea of synchronization is to make sure shared ... modifier may be quite usefull for multithreaded program. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Volatile + multithreading
    ... The volatile keyword has little use in multithreaded programming. ... > field or global seems to have no impact because it seems the compiler will ... operations as "special" and suppress optimizations around them. ... > majority of the multithreading issues that could have resulted from ...
    (microsoft.public.vc.language)
  • Re: mutex question
    ... Atomicity is a requirement for reading or writing? ... The 'volatile' keyword is useful with or without multithreading. ... Nor was it even strictly correct due to its use of printf in a thread created by CreateThread. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: mutex question
    ... I don't think I did attempt to define volatile: ... This was said by another person, and this is one of the standard definitions ... volatile is not useful for multithreading. ... C++, Windows, etc are neither necessary nor sufficient in the grand scheme ...
    (microsoft.public.win32.programmer.kernel)
  • Re: mutex question
    ... utility of the volatile keyword. ... You disputed somebody else's statements "about the utility of the volatile ... standard cannot be demonstrated if the standard is not cited. ... Well, under the POSIX standard, volatile is useless for multithreading. ...
    (microsoft.public.win32.programmer.kernel)
Loading