Re: Share .cpp and .h along projects

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Tue, 28 Aug 2007 12:38:48 -0500, "Ben Voigt [C++ MVP]"
<rbv@xxxxxxxxxxxxx> wrote:

It's "volatile-correctness" and prevents the object from being passed
someplace it shouldn't, just like const-correctness does:

class Example
{
char myarray[1000];

void doit() const
{
sprintf(myarray, "%d", 5);
}
};

Because myarray is a pointer-to-const inside a const member function
the compiler stops me from using it as the first argument to sprintf,
overwriting the data and breaking the "const" contract.

To be faithful to what you have been claiming, you should have used a
pointer, not an array. The "corrected" version of your example uses a
volatile pointer, not a pointer-to-volatile:

std::vector* volatile g_sharedVector;

This is perfectly fine:

std::vector* p = g_sharedVector;

Doesn't give you much "protection".

Similarly, because g_sharedVector is declared volatile, taking its address
yields a pointer-to-volatile, which the compiler will not permit to be
passed to a function that accepts a pointer to non-volatile. Interlocked***
can work on non-volatile variables, but volatile variables cannot be used by
anything but Interlocked*** and other functions designed for
synchronization. Just like non-const variables can be read, but marking a
variable as const means that it can only be read.

The only important thing in all this is your use of InterlockedXXX, which
allowed you to poorly imitate a mutex. Since you admit that InterlockedXXX
"can work on non-volatile variables", would you like to amend your earlier
claim:

any larger object can be controlled in a threadsafe
manner using a volatile pointer (which is word-sized) and memory barriers.

An accurate statement would be:

"It is possible to poorly emulate a mutex using pointers and
InterlockedExchangePointer."

However, you've been arguing the necessity of using volatile when
programming with mutexes, or as I sometimes call it, "volatile on top of
synchronization". I hope you understand now that volatile is not even
necessary for the correct operation of your example.

--
Doug Harrison
Visual C++ MVP
.

Relevant Pages

  • Re: Share .cpp and .h along projects
    ... Because myarray is a pointer-to-const inside a const member function ... pointer, not an array. ... volatile pointer, not a pointer-to-volatile: ... protecting it against simple assignment, ...
    (microsoft.public.vc.language)
  • Re: Share .cpp and .h along projects
    ... Because myarray is a pointer-to-const inside a const member function ... pointer, not an array. ... volatile pointer, not a pointer-to-volatile: ... Since you admit that InterlockedXXX ...
    (microsoft.public.vc.language)
  • Re: [PATCH 4/8] i386: bitops: Kill volatile-casting of memory addresses
    ... The "const volatile" is so that you can pass an arbitrary pointer. ... In other words, the "volatile" has nothing at all to do with whether the memory is volatile or not (the same way "const" has nothing to do with it: it's purely a C type *safety* issue, exactly the same way "const" is a type safety issue. ...
    (Linux-Kernel)
  • Re: Question about memcpy_fromio prototype
    ... The right thing for a read-only IO pointer is actually ... which looks funny ("const volatile"?) but makes sense for prototypes, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Share .cpp and .h along projects
    ... That wouldn't be correct without volatile. ... You used the InterlockedXXX API in your example. ... fine in VC2005 and later as long as the pointer is volatile. ... // use pvector in any way desired ...
    (microsoft.public.vc.language)