Re: mutex question

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

[...]

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). :)

This was said by another person, and this is one of the standard definitions
almost verbatim, plus some commentary.

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?

These two statement are slightly more balanced, not still not entirely
satisfactory. The original flat statement "X is not, Y is" was much less
satisfactory. This original statement was a redefinition not semantically
identical with the standard definitions.

[...]

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.

Reads and writes did happen; your "corrupt" involves an ad hoc assumption --
the atomicity of reads and writes.

I am condemning its usage though, because it is neither necessary (ever
for multithreading on Windows) nor sufficient (except in a few special
cases).

C++, Windows, etc are neither necessary nor sufficient in the grand scheme
of things.

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

You're trying to reduce the use of 'volatile' to a nonsensical situation and
then say that 'volatile' is useless. The essence of my argument is that this
very reduction is incorrect.

S


.

Relevant Pages

  • Re: Cant add a key in the registry
    ... Looks like the parent key is considered "Volatile" by Windows. ... Using the REG.exe to add a key in that location, reports this error: ...
    (microsoft.public.windowsxp.general)
  • Re: closesocket() blocks and never returns
    ... Read/write ordering does not really matter very much here. ... One shot polled variables are fine for use with volatile in this scenario, ... Note that Windows runs on different processor families as well as on SMP ...
    (microsoft.public.win32.programmer.networks)
  • Re: Basic c question from a newbie
    ... > Not the parameter is declared volatile, but the unsigned char ... If this is only used to access a flash memory, the 'volatile' ... fixes many of the shortcomings of Windows 98 SE". ...
    (comp.arch.embedded)
  • Re: closesocket() blocks and never returns
    ... Note that Windows runs on different processor families as well as on SMP ... Using volatile correctly is not enough on a multiprocessor system to ... guarantee that all CPUs see memory accesses in the same order ... ONLY when you are terminating the program, since socket handles could ...
    (microsoft.public.win32.programmer.networks)
  • Re: .NET Memory Model
    ... >> I believe the memory model is the same as Java, that is, vauge as can be. ... >> DLC should work on windows on 32bit processors with volatile, ...
    (microsoft.public.dotnet.framework.clr)
Loading