Re: Share .cpp and .h along projects
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:osa6d3lp2vb5b3k9pv44vju9qjaktngusf@4ax.com...
On Mon, 27 Aug 2007 14:17:34 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
Please note the fact that "it should not compile" is a minor part of the
question. I'm far more interested in what he thinks using volatile
accomplishes for his example.
You're right, I meant:
std::vector* volatile g_sharedVector;
Sorry about that. I thought you were challenging whether volatile was
needed at all, not where I'd put it.
As I said, "where you put it" was a MINOR part of the question. For
probably the 6th time at least, what do you think it ACCOMPLISHES in the
example you posted? That, of course, is the MAJOR part of the question. :)
I thought it was pretty clear, but if I need to be more specific, here
goes, "Explain, in your own words, what volatile does in your example, why
it's necessary, and what would happen if you were to remove it." Here,
I'll
repeat your example for you ("corrected", so to speak):
std::vector* volatile g_sharedVector;
...
{
std::vector* pvector = NULL;
// this is a spin-wait, efficient on SMP, but on a single processor
system a yield should be inserted
while (pvector == NULL) {
pvector = InterlockedExchangePointerAcquire(&g_sharedVector,
NULL);
}
// use pvector in any way desired
// with VC2005, can use "g_sharedVector = pvector;" instead
InterlockedExchangePointerRelease(&g_sharedVector, pvector);
}
What do you think volatile adds to your example? What do you think would
happen if you removed it altogether? Remember, this is an example of what
you asserted on 8/16, "any larger object can be controlled in a threadsafe
manner using a volatile pointer (which is word-sized) and memory
barriers."
(As I did in my reply on 8/17, I again ask you to forget about memory
barriers, which don't apply to uniprocessor and x86 SMP.) What in the
world
do you think "volatile" is doing for you here?
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.
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.