MSDN volatile sample

Hello everyone,


In the MSDN volatile sample,

http://msdn2.microsoft.com/en-us/lib...fd(VS.80).aspx

I do not understand what is the purpose of the sample. I have tried to remove the keyword volatile, and the result is the same. :-)

Any ideas?


thanks in advance,
George

Remove the volatile, then try with an optimised build.

Remove the volatile, then try with a system under heavy load.

Thanks Salem,


I have tried to make a optimized build (/O2), but still the same result. :-)

Well, I think the sample is dependent on system environment. Could you help to describe in your understanding in multi-threading or heavy workload environment, what is the sample tries to demonstrate?

Quote:

---

Originally Posted by Salem

Remove the volatile, then try with an optimised build.

Remove the volatile, then try with a system under heavy load.

---

regards,
George

The thing is that the processor registers are much faster than memory, so the compiler sometimes tries to optimize by storing a value or variable in a register instead of reading/writing to memory. Of course, this has its own set of problems as well, since other threads, for example, can't modify that variable then, because each thread has its own set of processor registers.
The keyword volatile tells the compiler that an external process, the OS or another thread might modify this variable and thus, the compiler cannot optimize it by storing it in a register.

This may or may not be required. Usually, the compiler is smart enough to realize to or not to optimize away variables into registers when used in different threads, so the results may vary. But if you find that a thread tries to modify a variable and its value isn't changed in another thread, then you might need to add volatile to the variable.

Quote:

---

Originally Posted by Elysia

Usually, the compiler is smart enough to realize to or not to optimize away variables into registers when used in different threads, so the results may vary.

---

Don't think so. C/C++ compilers don't know anything about threads. That's why there is the volatile keyword it tells the compiler that something unexpected might happen.
Kurt

Maybe and maybe not. But the compiler can assume all sorts of things. Tricky creatures.
I haven't had the need to use the volatile keyword yet (and I have messed with plenty of threads), so that tells me that the compiler is intelligent beast and the volatile keyword is not always (if rarely?) needed.

You know that a c/c++ compiler doesn't know anything about the final executable that will created, don't you. It's the linker that does that job. The compiler sees only rather small parts ( modules ) so how would it ever know how that modules will finally be used ?
There is no way for the compiler to know when it is allowed to optimize away a variable into a register. This info has to be given to the compiler, hence the volatile keyword.

Quote:

---

Originally Posted by Elysia

I have messed with plenty of threads

---

You were lucky.
Kurt

Hi Elysia,


Even though in my specific environment, I can not find any differences. What do you expect the different results MSDN sample will be compared with adding/removing volatile keyword?

Quote:

---

Originally Posted by Elysia

The thing is that the processor registers are much faster than memory, so the compiler sometimes tries to optimize by storing a value or variable in a register instead of reading/writing to memory. Of course, this has its own set of problems as well, since other threads, for example, can't modify that variable then, because each thread has its own set of processor registers.
The keyword volatile tells the compiler that an external process, the OS or another thread might modify this variable and thus, the compiler cannot optimize it by storing it in a register.

This may or may not be required. Usually, the compiler is smart enough to realize to or not to optimize away variables into registers when used in different threads, so the results may vary. But if you find that a thread tries to modify a variable and its value isn't changed in another thread, then you might need to add volatile to the variable.

---

regards,
George

Hi Kurt,


What different behaviors do you expect if we remove the volatile keyword in MSDN sample?

If there is actually a different behavior, I suspect this is a bug -- optimization changes the multi-thread application's behavior.

Quote:

---

Originally Posted by ZuK

Don't think so. C/C++ compilers don't know anything about threads. That's why there is the volatile keyword it tells the compiler that something unexpected might happen.
Kurt

---

regards,
George

Quote:

---

Originally Posted by George2

Hi Elysia,

Even though in my specific environment, I can not find any differences. What do you expect the different results MSDN sample will be compared with adding/removing volatile keyword?

regards,
George

---

I expect it will still work. The volatile variable is global and is used in several functions, so there is a good chance the compiler won't cache the value in a register at all. This may or may not be the case as there's no guarantee the compiler will do this. It may or it may not run. It may cause racing conditions, too.

There's a good chance there might be racing condition for code such as this. If you wonder what a racing condition is, it's when two or more threads are fighting over the same data. Thread 1 might attempt to write data to some data that thread 2 uses currently. This does not always happen due to how threads are scheduled, thus it's called a racing condition. It can happen, but it doesn't always.

It's difficult to say. Perhaps if we took a look at the assembly code, we could say more.

And btw, you can edit your posts and do a multi-quote instead of posting a reply for each one you're quoting.

Thanks Elysia,


This is the code which makes me confused in MSDN sample.

Code:

---

    while (Sentinel)
    {
      Sleep(0);
    }

---

I think when thread1 enters into the while loop, the value of Sentinel is true and it should invokes Sleep(0). Sleep(0) will wait until there is a signal. But in the program no other parties send thread1 a signal, and I think thread1 will wait forever to cause deadlock. :-)

The only reason why there is no deadlock is when thread1 checks variable Sentinel, it happens to be false changed by thread2.

Anything wrong with my previous analysis? Please feel free to correct me.

Quote:

---

Originally Posted by Elysia

And btw, you can edit your posts and do a multi-quote instead of posting a reply for each one you're quoting.

---

Good idea. I will try my best to follow in the future.


regards,
George

Actually, Sleep(0) tells the OS that the thread yields its current execution time slice. So if a thread executes 10 ms, pauses for 5 ms, then executes for another 10 ms, the behavior will be 1 ms execution time, remaining 9 ms is yielded, so it waits 9 + 5 ms, then the thread will execute again and the process repeats itself until Sentinel is false.

This is another case where MS is confusing the hell out of everybody.....

First, from a standards perspective, the volatile keyword is only useful when used with sig_atomic_t inside a signal handler. The standard does provide other "semantics" to volatile objects but those can't be applied to multi-threading. Basically, what the standard provides for volatile objects is a defined ordering of reads and writes with respect to other volatile objects. It's been a great source of debate as to what this really means to compiler implementors and what guarantees this gives the programmer. Because of this, the general consensus that I've gathered over the years is that any use of volatile other than "volatile sig_atomic_t" is implementation defined.

A note on re-ordering.....

There are two ways in which reads and writes to memory can become "re-ordered". The first way is that the compiler itself is free to re-order reads and writes. For example:

Code:

---

int v1, v2;
...
v1 = 1;
...
v2 = 2;

---

In this example, the compiler is free to perform "v2 = 2" first. Now consider:

Code:

---

volatile int v1, v2;
...
v1 = 1;
...
v2 = 2;

---

Now the compiler must perform "v1 = 1" first. It's also commonly accepted that a compiler implementation should translate each read or write of a volatile object into an actual read or write on the address bus. In other words, volatile objects shouldn't be cached in a CPU register.

The other way in which reads and writes can be re-ordered arises from the hardware itself. On some architectures the processor can re-order the sequence of read and write instructions before executing those instructions. Also, on some architectures the cache-coherency algorithms used between cores can result in reads and writes appearing as if they were performed in a different order. Both of these issues are solved using "memory barriers". In general, a full (or fence) mbar means that all cores (and associated cache-lines) are "in-sync" with each other. There are also "acquire" and "release" mbars which are less restrictive than a full mbar.

The great debate: to volatile, or not to volatile in MT.....

So what does all this mean with respect to multi-threaded programming? Unfortunately, this has also been a great source of debate - which makes finding a definitive answer on the NET and news groups difficult. Under POSIX, things are more clear since POSIX defines memory coherency guarantees in a multi-threaded environment. Under POSIX, the only use of volatile is with sig_atomic_t in signal handlers or for memory mapped I/O (where each read or write must translate to a read or write on the address bus). If you're doing non-POSIX, multi-threaded programming, then you're in "implementation defined" territory when it comes to memory coherency guarantees.

Defined Implementation of the Microsoft compiler....
Starting with version 14.0.0 of the MS compiler, the volatile keyword was given additional semantics for use in a multi-threaded environment. From that version forward, reads from volatile objects generate an implied "acquire mbar" and writes to volatile objects generate an implied "release mbar". Note that this is only on architectures that support acquire and release mbars. MS-bashers out there like to suggest that MS made this move so that incorrectly written multithreaded device drivers and applications, which only used the volatile keyword as a means of shared variable synchronization, would simply start working correctly after re-compiling with version 14 or higher. In any case, here's a direct quote from a MS document on the use of volatile:

Quote:

---

Originally Posted by Microsoft Document - Multiprocessor Considerations for Kernel-Mode Drivers

If you look at the sample drivers shipped with the Windows DDK, you will see that volatile appears infrequently. In general, volatile is of limited use in driver code for the following reasons:
• Using volatile prevents optimization only of the volatile variables themselves. It does not prevent optimizations of nonvolatile variables relative to volatile variables. For example, a write to a nonvolatile variable that precedes a read from a volatile variable in the source code might be moved to execute after the read.
• Using volatile does not prevent the reordering of instructions by the processor hardware.
• Using volatile correctly is not enough on a multiprocessor system to guarantee that all CPUs see memory accesses in the same order.
Windows synchronization mechanisms are more useful in preventing all these potential problems.

---

Conclusion? In my opinion, volatile has no use in multi-threaded programming. MSVC is the only compiler I know of that actually defines volatile semantics in a multi-threaded environment - and even then MS themselves admit that "volatile is of limited use".

If you look closely at the MSDN page on volatile, there's a big chunk of the remarks section between "[Microsoft Specific]" and "[End Microsoft Specific]". What it doesn't tell you is that the example code demonstrates and relies only on the "Microsoft Specific" implementation of volatile. That example code is not even correct when using a MSVC version prior to 14! The best thing to do is to use proper synchronization primitives provided by the Windows SDK so that your code is correct regardless of the compiler being used......MSVC new and old, mingw, Borland C++, etc..., etc...

gg

Some people are making the observation that a global variable has to have a specific address in memory, otherwise how could different modules share the same variable? This is correct, but not the entire picture.

Declaring a variable "volatile" means that the value in RAM must be up to date at all times. For instance, consider:

Code:

---

int x = 0;

int frob_x()
{
    x = (15 - x) * x + 1;
    x += 1;
    x /= 5;
}

---

While it is true that x has an address, being a global object, that does not mean that the value at this address is up to date. During the execution of frob_x() the compiler is free to cache the value of x inside a register until the function returns or calls another function. The value in memory does not necessarily go through the transformations seen in the code. That might happen only inside a register. Once frob_x() returns the value will be written back.

This might seem okay, but consider two threaded functions using a condition variable. One thread wakes up the other. The woken thread tests the value of the condition -- if false, it goes back to sleep again.

What if the condition is the value of a global variable? Both threads are running inside isolated functions. The compiler may have caused updates to the global condition to be done inside a register, since it is allowed to do so. The compiler has no idea about the existence of separate threads. So, when one thread sets "condition = 1;" this may just cause some register to change value. The other thread will never know of the change in value.

The variable MUST be declared "volatile" to cause the compiler to store its value up to date at all times.

Codeplug, you made an interesting post. But this does not change the fact that the in-memory value of a volatile variable is guaranteed to be equal to the semantic value of that variable at each sequence point, I believe that IS guaranteed by the standard. You are correct that volatile alone is not always enough to guarantee safety in multithread contexts, but it is definitely required.

>> You are correct that volatile alone is not always enough to guarantee safety in multithread contexts, but it is definitely required.
volatile is not required in multi-threaded programming. You can use it if you choose, but then you are at the mercy of the compiler implementation.

>> The variable MUST be declared "volatile" to cause the compiler to store its value up to date at all times.
This is a correct statement, but not sufficient for MT contexts on all architectures (as you mention).

In other words, any multi-threaded code that uses the volatile keyword can be re-written correctly without using volatile. The resulting code will then be much more "compiler agnostic" while still being correct. If you are relying on your compilers documented volatile semantics, then that code should be wrapped in #ifdef MY_COMPILER_IN_USE.

The use of the volatile keyword in C++ brings up even more issues. Here's a good news group thread that summarizes the debate fairly well.
http://groups.google.com/group/comp....7c34cd66113e7/

gg

The only thing I took away from that discussion was that you don't need volatile because you can always make a call to a "dummy function" which forces the compiler to synchronize the memory location. While true, it seems like a dorky hack.

Also, it seems this approach would not work with a non-global variable, for instance a variable accessed through a pointer which is shared between threads. The pointer itself might be synchronized, but the value it points to won't be, unless it is declared volatile.

You could write thread safe code without volatile, just as you could build a house with no nails, but it's not inherently a better or worse way of doing things. Just be aware that volatile makes guarantees about the reads and writes on specific variables, not the interactions between those variables. You still have to understand barriers, etc.

>> The only thing I took away from that discussion was that you don't need volatile...
That was my conclusion as well.

gg

You're always at the mercy of the implementation. C++03 doesn't have the concept of parallel execution. The memory model does not support it. The execution model does not support it. The moment you call any thread creation function, you're in implementation-defined area.

Quote:

---

Originally Posted by Codeplug

>> The only thing I took away from that discussion was that you don't need volatile...
That was my conclusion as well.

gg

---

Cutting my quote off to make me look like I'm agreeing with you is dumb.

Well I certainly didn't quite take away with me the understanding that the volatile keyword should never be used, after reading those. It's perhaps compiler dependent though.
I might not go overboard and use it everywhere I think there might otherwise be a problem, but you can be damn sure that if there is an intermittent problem in my multi-threaded code that it'll be one of the things I'll try!

Any thoughts on atomic operations and why functions like InterlockedIncrement have a volatile pointer as their parameter? Is that necessary?
http://paste.lisp.org/display/53106/raw
Actually the "register volatile" stuff seems a bit strange...

From a debate point of view, here are my assertions:
1) This is a non-POSIX environment debate - thanks to the memory visibility guarantees given by POSIX.
2) There is no standard, including POSIX, which gives any meaningful semantics to applying volatile to a *shared* object. (*shared* = accessed by multiple threads).
3) Therefore, any meaningful semantics must come from the compiler (documentation).

Why write code that's bound to "implementation defined" behavior - specially when the same code can be written without "implementation defined" behavior?

>> Any thoughts on atomic operations and why functions like InterlockedIncrement have a volatile pointer as their parameter?
volatile was added to the Interlocked API's sometime after the VC++ 6.0 SDK. (Found a reference that said the signatures changed in the July 2001 PSDK.)
This has always baffled me. While searching the groups for some answers, I found this great thread in microsoft.public.msdn.general:
http://groups.google.com/group/micro...2a440f44693ea7
I say "great" not only because my position is backed by a couple of MSMVP's - which prob. ain't say'n much :) - but it also has a couple guesses as to why volatile was added to the Interlocked API's.

There's plenty of further reading on this subject - for those who like to dig. Summaries and more links here:
http://groups.google.com/group/comp....5048032700caf/

gg

Ok well regardless of what the C++ standard standpoint is, the fact is that the volatile keyword is still part of C++, and afaik still has the effect it always had in VS2008, 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?
Now even though you're quite possibly right, Microsoft presumably still feel that it is necessary. Otherwise surely they would take the same route as with 'register', and 'inline' and simply ignore the keyword. (Please let me know if they actually have in VS2008).
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. Obviously it is still of some use, or even perhaps necessary in some circumstance, even if that usage is to prevents bugs appearing in their own code, or as a potential workaround for possible compiler bugs. Never say never.

There's been a lot of talk about implementation defined behaviour too, most of which is implying it is a bad thing. That's not entirely true. Sure it can be good to have standard defined behaviour for portability, but in many areas of C++ there just isn't strict standards around detail of that part of the language. Sometimes the implementation defined behaviour is exactly what you want. Also, sometimes porting the code is just never going to happen anyway.

VC9 refuses to cache global variables in a register, it seems:

Code:

---

for (int i = 0; i < 0xFFFFFFFF; i++)
00401821  xor        esi,esi
        {
                MyGlobalVar++;
00401823  inc        dword ptr [MyGlobalVar (404384h)]
                if (i &#37; 1000) cout << MyGlobalVar << endl;
00401829  mov        eax,10624DD3h
0040182E  imul        esi 
00401830  sar        edx,6
00401833  mov        eax,edx
00401835  shr        eax,1Fh
00401838  add        eax,edx
0040183A  imul        eax,eax,3E8h
00401840  mov        ecx,esi
00401842  sub        ecx,eax
00401844  je          Help+47h (401867h)
00401846  mov        edx,dword ptr [__imp_std::endl (402048h)]
0040184C  mov        eax,dword ptr [MyGlobalVar (404384h)]
00401851  mov        ecx,dword ptr [__imp_std::cout (40204Ch)]
00401857  push        edx 
00401858  push        eax 
00401859  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (402040h)]
0040185F  mov        ecx,eax
00401861  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (402044h)]
00401867  inc        esi 
00401868  cmp        esi,0FFFFFFFFh
0040186B  jb          Help+3 (401823h)
0040186D  pop        esi 
        }

---

If, on the other hand, it's a local var, it's cached in a register:

Code:

---

        for (int i = 0; i < 0xFFFFFFFF; i++)
00401824  xor        esi,esi
        {
                MyLocalVar++;
                if (i % 1000) cout << MyLocalVar << endl;
00401826  mov        eax,10624DD3h
0040182B  imul        esi 
0040182D  sar        edx,6
00401830  mov        eax,edx
00401832  shr        eax,1Fh
00401835  add        eax,edx
00401837  imul        eax,eax,3E8h
0040183D  mov        ecx,esi
0040183F  inc        edi 
00401840  sub        ecx,eax
00401842  je          Help+40h (401860h)
00401844  mov        edx,dword ptr [__imp_std::endl (402048h)]
0040184A  mov        ecx,dword ptr [__imp_std::cout (40204Ch)]
00401850  push        edx 
00401851  push        edi 
00401852  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (402040h)]
00401858  mov        ecx,eax
0040185A  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (402044h)]
00401860  inc        esi 
00401861  cmp        esi,0FFFFFFFFh
00401864  jb          Help+6 (401826h)
00401866  pop        edi 
00401867  pop        esi 
        }

---

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.
I'm not an expert at assembly, so if anyone wants to take a look at what's really happening, feel free. I'll post the assembly code too.

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);
}

---

Code:

---

00401950  sub        esp,8
        volatile UINT MyLocalVar = 0;
00401953  mov        dword ptr [esp],0
        CWinThread* pThread;
        Stuff::NewThreadTF(&pThread, MyLocalVar, &Thread1);
0040195A  mov        eax,dword ptr [esp]
0040195D  push        edi 
0040195E  push        eax 
0040195F  lea        edi,[esp+0Ch]
00401963  call        Stuff::NewThreadTF<unsigned int,void (__cdecl*)(int const &)> (401000h)
00401968  add        esp,4
0040196B  or          eax,0FFFFFFFFh
0040196E  mov        ecx,1
00401973  pop        edi 
        for (int i = 0; i < 0xFFFFFFFF; i++)
        {
                MyLocalVar++;
00401974  add        dword ptr [esp],ecx
00401977  sub        eax,ecx
00401979  jne        Help+24h (401974h)
                //if (i % 1000) cout << MyLocalVar << endl;
        }
        //Stuff::NewThreadTF(&pThread, NULL, &Thread2);
        //Sleep(3000);
        bExit = true;
0040197B  mov        byte ptr [bExit (404384h)],cl
        WaitForSingleObject(pThread->m_hThread, INFINITE);
00401981  mov        ecx,dword ptr [esp+4]
00401985  mov        edx,dword ptr [ecx+2Ch]
00401988  push        0FFFFFFFFh
0040198A  push        edx 
0040198B  call        dword ptr [__imp__WaitForSingleObject@8 (40202Ch)]

---

Quote:

---

Originally Posted by iMalc

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

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.

You may be right. I think the compiler is a little poor in this regard. It didn't even catch my mistake of using UINT and passing it as int.
Anyway, I updated the code, but the problem remains:

Code:

---

bool bExit = false;

void Thread1(volatile const UINT& 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 &#37; 1000) cout << MyLocalVar << endl;
        }
        bExit = true;
        WaitForSingleObject(pThread->m_hThread, INFINITE);
}

---

Code:

---

00401940  sub        esp,8
        volatile UINT MyLocalVar = 0;
00401943  mov        dword ptr [esp],0
        CWinThread* pThread;
        Stuff::NewThreadTF(&pThread, MyLocalVar, &Thread1);
0040194A  mov        eax,dword ptr [esp]
0040194D  push        edi 
0040194E  push        eax 
0040194F  lea        edi,[esp+0Ch]
00401953  call        Stuff::NewThreadTF<unsigned int,void (__cdecl*)(unsigned int const volatile &)> (401000h)
00401958  add        esp,4
0040195B  or          eax,0FFFFFFFFh
0040195E  mov        ecx,1
00401963  pop        edi 
        for (int i = 0; i < 0xFFFFFFFF; i++)
        {
                MyLocalVar++;
00401964  add        dword ptr [esp],ecx
00401967  sub        eax,ecx
00401969  jne        Help+24h (401964h)
        }
        bExit = true;
0040196B  mov        byte ptr [bExit (404384h)],cl
        WaitForSingleObject(pThread->m_hThread, INFINITE);
00401971  mov        ecx,dword ptr [esp+4]
00401975  mov        edx,dword ptr [ecx+2Ch]
00401978  push        0FFFFFFFFh
0040197A  push        edx 
0040197B  call        dword ptr [__imp__WaitForSingleObject@8 (40202Ch)]

---

(Never used volatile before, so there's my problem I didn't catch a mistake like that ;))

Here's one way of writing the same code, but which uses correct synchronization for all Windows compilers and 32bit architectures. It uses just the Win API so anyone with a windows compiler can play with it.

I pulled InterlockedRead() from my own source. The nice thing about wrapping templates around the Interlocked functions is that you can use template-techniques to automatically choose the 64bit Interlocked API's at compile time (not shown here). Then the code would be correct for all supported Windows architectures.

Code:

---

#include <windows.h>

#include <iostream>
using namespace std;

/*------------------------------------------------------------------------------
InterlockedRead - Read a "stable" value in an Interlocked fashion. Returns the
                  the true value of the pointer "at the time" this function
                  returns. This is really only useful for "read with full memory
                  barrier" semantics.
------------------------------------------------------------------------------*/
template<typename T>
T InterlockedRead(T *psrc)
{
    T val;
    for (;;)
    {
        val = *psrc;
        if ((T)InterlockedCompareExchange((LONG*)psrc, (LONG)val, (LONG)val)
                == val)
            break;
    }//if

    return val;
}//InterlockedRead

/*----------------------------------------------------------------------------*/

struct MyThreadParams
{
    LONG ThreadExit;
    LONG ThreadVal;
};//MyThreadParams

DWORD WINAPI MyThread(LPVOID param)
{
    MyThreadParams *pp = reinterpret_cast<MyThreadParams*>(param);
    LONG last_val = -1;

    while (!InterlockedRead(&pp->ThreadExit))
    {
        int cur_val = InterlockedRead(&pp->ThreadVal);
        if (cur_val != last_val)
        {
            cout << cur_val << endl;
            last_val = cur_val;
        }//if

        Sleep(0);
    }//while
       
    return 0;
}//MyThread

/*----------------------------------------------------------------------------*/

int main()
{
    MyThreadParams tparam = {0};
    HANDLE h = CreateThread(0, 0, &MyThread, &tparam, 0, 0);
    if (!h)
    {
        cerr << "CreateThread() failed, ec = " << GetLastError() << endl;
        return 1;
    }//if
   
    for (int n = 0; n < 10; ++n)
    {
        InterlockedIncrement(&tparam.ThreadVal);
        Sleep(750);
    }//for

    InterlockedIncrement(&tparam.ThreadExit);
    WaitForSingleObject(h, INFINITE);

    cout << "Thread is done" << endl;

    return 0;
}//main

---

Keep in mind that volatile is treated just like const. So using the debate angle of "MS put volatile on the Interlocked API's for some reason - so we should use volatile variables" doesn't really make sense. That would be the same as saying "strlen() takes a const pointer, so all variables passed to strlen() should already be const". In other words, non-volatile objects are automatically promoted to volatile objects without a cast - same as with const.

So the question is - why did MS slap volatile qualifier on the Interlocked pointer parameters? The conclusion reached in many news group threads (and by MS-MVP's) is that is was an unnecessary and poorly conceived change.

More threds....

http://groups.google.com/group/comp....4a82dda916b18/
This is an interesting debate to read. Around post 18 they start to get into what benefits, if any, was MS thinking of when they added volatile to Interlocked API's. Conclusion: there are no benefits, and it promotes and confuses folks into poor MT programming.

http://groups.google.com/group/micro...f861788a8ecf8f
I like this thread for 2 reasons, it's a fairly recent thread, and it's another MS-MVP agreeing with me :)

Quote:

---

Originally Posted by Doug Harrison - Visual C++ MVP

...if you're using synchronization, you don't need
volatile, because synchronization provides the desired memory consistency
between the threads; indeed, the only thing using volatile on top of
synchronization does is kill performance.

---

gg

Quote:

---

Originally Posted by CornedBee

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.

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.

---

Thankyou for your response, and forgive my lack of understanding, but what is volatile actually useful for in single-threaded programming? Oh I suppose it's compiler or platform specific right?

Sorry, I wasn't actually meaning to suggest dropping the keyword.

Using volatile on simple things, like local variables, is extremely useless. You can use volatile for global variables of type sigatomic_t if you want to react to signals. (Standard C and C++ acknowledge the existence of POSIX-like signals, even though they don't provide a way to fire them, or give any information about when one might be fired.)
You would also probably use volatile for pointers to memory-mapped I/O address ranges. At any time, there might be an interrupt and the device could change the contents of this area. This is stuff that comes from the system-level programming part of C++ and is not really useful in application-level programming.

Actually, the only time I've used volatile was when I wanted to force the compiler away from some optimizations, e.g. to observe the effect of some code and prevent the compiler from just optimizing it away.

In a previous thread I posted, Alexander Terekhov summed up legal usage of volatile - down in post 42.
http://groups.google.com/group/comp....1a34f888b85281

The last time I used volatile (correctly) was in an embedded system using a MIPS CPU. This CPU used memory mapped registers for all the on-CPU functionality. Even the interrupt mask register could be accessed by via a *special* memory address, even though it could be referenced explicitly in assembly. Basically the way it worked is the CPU would "intercept" any access to the address bus if the address was a *special* address - it would then re-route to access to the mapped register. In C, the register could then be directly read and written to using a volatile pointer. The reason the pointer is volatile is so that the compiler can't re-order accesses and so that each access in C code translates to an access to the address bus.

gg

I agree all of your points, CornedBee!


You know, the conflicting points about this thread is not about the below points, but how should we use volatile in multi-threading programming. :-)

It is appreciated if you could give us some final insights. :-)

Quote:

---

Originally Posted by CornedBee

Using volatile on simple things, like local variables, is extremely useless. You can use volatile for global variables of type sigatomic_t if you want to react to signals. (Standard C and C++ acknowledge the existence of POSIX-like signals, even though they don't provide a way to fire them, or give any information about when one might be fired.)
You would also probably use volatile for pointers to memory-mapped I/O address ranges. At any time, there might be an interrupt and the device could change the contents of this area. This is stuff that comes from the system-level programming part of C++ and is not really useful in application-level programming.

Actually, the only time I've used volatile was when I wanted to force the compiler away from some optimizations, e.g. to observe the effect of some code and prevent the compiler from just optimizing it away.

---

have a good weekend,
George

Hi Codeplug,


But the #42 post does not mention how to use volatile together with multi-threading programming. :-)

This is the key points we discuss and do not agree with each other at the beginning. I am not sure whether you could give your final points of how to use volatile in multi-threading environment?

Quote:

---

Originally Posted by Codeplug

In a previous thread I posted, Alexander Terekhov summed up legal usage of volatile - down in post 42.
http://groups.google.com/group/comp....1a34f888b85281

The last time I used volatile (correctly) was in an embedded system using a MIPS CPU. This CPU used memory mapped registers for all the on-CPU functionality. Even the interrupt mask register could be accessed by via a *special* memory address, even though it could be referenced explicitly in assembly. Basically the way it worked is the CPU would "intercept" any access to the address bus if the address was a *special* address - it would then re-route to access to the mapped register. In C, the register could then be directly read and written to using a volatile pointer. The reason the pointer is volatile is so that the compiler can't re-order accesses and so that each access in C code translates to an access to the address bus.

gg

---

regards,
George

Great reply, Codeplug!


I have taken a long time to read it. And really learned a lot. Since you mentioned, there is no use to use volatile in multi-threading environment, I am not sure whether you have read this article or not from my other reply.

http://www.ddj.com/cpp/184403766

The points from the article are,

(you can refer to section "volatile, Critical Sections, and Race Conditions" of this article)

1. No need to use volatile for thread shared data in synchronized section (e.g. mutex and critical section);
2. Need to use volatile for thread shared data in non-synchronization section.

I am not sure whether you have any comments. :-)

Quote:

---

Originally Posted by Codeplug

Conclusion? In my opinion, volatile has no use in multi-threaded programming. MSVC is the only compiler I know of that actually defines volatile semantics in a multi-threaded environment - and even then MS themselves admit that "volatile is of limited use".

gg

---

regards,
George

Come on. Are we going to continue posting 2/3/4/5 times in a row?
Press the quote button, copy the contents in the reply box, cancel, press edit, paste, write a new reply.
You do realize that double posting is usually frowned upon on forums, unless under certain circumstances. Thrice or more even more so frowned upon and disliked.

Hi brewbuck,


I have a useful Dr. Dobb article of this topic, and I post the related points to #32 post of this thread. It is appreciated if you could review and comment whether you agree with the points or not. :-)

Quote:

---

Originally Posted by brewbuck

Codeplug, you made an interesting post. But this does not change the fact that the in-memory value of a volatile variable is guaranteed to be equal to the semantic value of that variable at each sequence point, I believe that IS guaranteed by the standard. You are correct that volatile alone is not always enough to guarantee safety in multithread contexts, but it is definitely required.

---

regards,
George

Hi brewbuck,


What do you mean "dummy function"? Could you show some pseudo code please?

Quote:

---

Originally Posted by brewbuck

The only thing I took away from that discussion was that you don't need volatile because you can always make a call to a "dummy function" which forces the compiler to synchronize the memory location. While true, it seems like a dorky hack.

---

regards,
George

Hi CornedBee,


It is appreciated if you could comment what exactly do you mean "implementation-defined area" in your below reply. I am still unclear after reading your reply for a couple of times. :-)

Quote:

---

Originally Posted by CornedBee

You're always at the mercy of the implementation. C++03 doesn't have the concept of parallel execution. The memory model does not support it. The execution model does not support it. The moment you call any thread creation function, you're in implementation-defined area.

---

regards,
George

Hi iMalc,

Quote:

---

Originally Posted by iMalc

I might not go overboard and use it everywhere I think there might otherwise be a problem, but you can be damn sure that if there is an intermittent problem in my multi-threaded code that it'll be one of the things I'll try!

---

As you mentioned above, have you got any result after trying? :-)


have a good weekend,
George

Another 4 posts in a row. Use multi-quote or edit!

Wow, your reaction to my PM lasted a whopping single post.

What I mean is that C++ isn't multi-threaded. The idea isn't there in the C++ execution model. The moment you create a second thread, the C++ standard has nothing more to say about the behaviour of your program. It's all up to your specific environment.