UPDATE: I asked this question in another form (see below), and it got closed for being not constructive. Kind of a shame since the answers exactly dealt with what I asked (and solved my problem), but I’m new here so I will certainly try again to make it more constructive.
I am working in VC++, under Windows 7. My multi-threaded program assigns values to variables in one thread, then sends a signal via an event object to a different thread that is blocked, waiting for that signal. Owing to things like optimizations contributed by the compiler, there is no guarantee that data assigned to a variable by one thread will actually be available to the other thread, even if one is sure (via the blocking mechanism) that the other thread will not attempt access until a time after the data has been assigned to the variable. For example, the value may be in a CPU register, remaining there until that register is needed for something else. This can avoid unnecessary loads from memory if the value is needed again soon after it was put into that register. Unfortunately, that means the corresponding location in memory continues to hold the last value it held prior to the new value being assigned. Thus, when the other thread unblocks, and accesses the memory holding the variable’s value, it will obtain the old value, not the one most recently assigned.
The question, then, is: How does one Windows thread enforce storage to memory of values it assigns to variables, so that another thread is sure to have access to them at a later time? There may be several answers, but the one offered before this question was closed that seemed to be the best fit for what I needed was the use of a “memory fence,” which was a programming construct I had not previously heard of. After the fence is encountered, pending writes to memory are guaranteed to have completed. (That’s if the fence is a “write” fence; one can force a read from memory with a “read” fence, and one can do both with a “read/write” fence. Windows makes all three available quite easily within a VC++ program.)
One slight gotcha turned out to be that Windows fences (aka “memory barriers”) only apply their guarantees to global, not local, storage (for reasons explained on the applicable MSDN pages).
If my interpretation here of how memory fences work is incorrect (and the moderators ever re-open this question), I’d be pleased to see that explained in the comments. I wouldn’t ask if I weren’t humble enough to admit I didn’t know, after all. (If the moderators don’t re-open it, but you can see I’ve got something wrong, please drop me an e-mail and let me know; I’ll be glad to help keep this discussion alive at my blog, if you do.)
ORIGINAL VERSION
What’s a good way to share data between threads?
I asked a question earlier about volatile variables that opened up an enormous learning experience for me. Among other things, I realized I wasn’t asking the right question. Hope this isn’t bad stackoverflow etiquette, but I think I should create a new question here that addresses my underlying issue:
I have two threads, A and B, in my Visual C++ program. B is blocked, waiting for a signal from A. A sets a number of variables. A then signals B, which will read the variables set by A. I am concerned that some of the variables set by A may not actually be written back to memory, as they may only reside in CPU registers.
What is a good way to be sure that thread B will, upon reading the variables previously set by thread A, read the values that thread A set?
Under an x86 architecture there is not much to worry about when using a good library.
Guard the access to the shared data using mutexes (for instance boost::mutex) and if the implementor of the mutex did it right, then s/he will have used a memory barrier (Memory Barriers @ MSDN) to ensure that caches have been flushed to memory.
If you had to write your own sync code, then add memory barriers to it.