Quote Originally Posted by iMalc View Post
and afaik InterlockedIncrement etc still takes a volatile pointer in VS2008. I don't have VS2008 at home so perhaps someone else could confirm this?
InterlockedIncrement is part of the Win32 SDK and independent of VS versions.

Now even though you're quite possibly right, Microsoft presumably still feel that it is necessary.
Yes, but possibly simply for source compatibility. You can't just drop the volatile keyword, just as you can't just drop the const keyword.

Otherwise surely they would take the same route as with 'register', and 'inline' and simply ignore the keyword.
Ah, no, they can't do that. For single-threaded applications, volatile still has a certain effect required by the standard. Register and inline are just suggestions, volatile is not.

As long as it is still there and still does what it is supposed to, it's hard to imagine that we are never intended to use it.
The thing is, there's no agreement on what it is supposed to do in multi-threaded code.

Quote Originally Posted by Elysia View Post
Following doesn't work, because even though the variable is volatile, it actually writes the value to a different address than the MyLocalVar, as its value doesn't change.
Code:
bool bExit = false;

void Thread1(const int& rMyLocalVar)
{
	while (!bExit)
	{
		cout << rMyLocalVar << endl;
		Sleep(100);
	}
}

void Help()
{
	volatile UINT MyLocalVar = 0;
	CWinThread* pThread;
	Stuff::NewThreadTF(&pThread, MyLocalVar, &Thread1);
	for (int i = 0; i < 0xFFFFFFFF; i++)
	{
		MyLocalVar++;
		//if (i % 1000) cout << MyLocalVar << endl;
	}
	bExit = true;
	WaitForSingleObject(pThread->m_hThread, INFINITE);
}
This shouldn't even compile! volatile is sticky, like const. You shouldn't be able to pass the volatlie MyLocalVar to the non-volatile parameter of Thread1. Either VS doesn't enforce this properly, or you have an evil cast going on.