How to insure variables are stored to memory before different thread reads them

Question

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?

Answer 1

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.

Answer 2

You mentioned in a comment, My particular problem is in being able to guarantee that, once unblocked, a thread will actually have access to values written to shared locations by the other thread.

I believe the answer to your question is simple: you can use _ReadWriteBarrier() (or, in your particular case, probably just _WriteBarrier inside the reading threads will do) to ensure that you read up-to-date memory values.

Note that, as far as I know, in C/C++, volatile is not guaranteed to have any memory barrier semantics -- so you can't simply use volatile in those languages. Memory barriers are the way to go for simply reading up-to-date values.

Answer 3

This is like asking "what's a good way to write an object-oriented program." Except to that question I would say "go read a good book," but to this one, there really isn't a good book on a bad paradigm. A lot of multithreaded programming is based on minimizing use of shared data rather than using it well.

So, my suggestions are:

1) Design so that no two threads need to communicate with each other in this way. Sounds more like one procedural thread is going on here than two truly independent threads.

2) Implement a service-oriented architecture within your process or between processes. Make all shared data occur over ephemeral request/response patterns rather than relying on the use of global variables that are polled. All these variables that A sets and tells B to read sounds a lot like a "request" that "client" A is sending to "server" B.

3) If you're OK with installing and putting effort into learning a library, I recommend ZMQ. I've had good experience with it and they advertise (and in my experience deliver) their tool, which on the service looks like a library to implement clients and servers in, as a way to get rid of all shared data between threads. If nothing else the documentation might give you good ways to think about cashing in your shared data between threads for patterns that don't involve them instead.

Answer 4

If you mean, "How do I synchronize access to prevent race conditions?" I think I've got that managed by having each thread block while waiting for a signal from the other. My particular problem is in being able to guarantee that, once unblocked, a thread will actually have access to values written to shared locations by the other thread.

Yes, exactly. The problem is that waiting on a signal set by some thread is not enough to ensure that any of that thread's other activities are visible from the current thread. A thread can set a variable, trigger the signal, and then a thread waiting on the signal can access the variable, but get a completely different value.

I'm currently enjoying Anthony Williams' book, C++ Concurrency in Action, on this topic. The answer seems to lay in using std::atomic memory orders correctly. Here's an example:

std::atomic<bool> signal(false);
std::atomic<int> i(0);

-- thread 1 --
i.store(100,std::memory_order_relaxed);
signal.store(true,std::memory_order_release);

-- thread 2 --
while(!signal.load(std::memory_order_acquire));
assert(i.load(std::memory_order_relaxed) == 100);

When the second thread sees the signal, a relationship is established between the store performed with memory_order_release and the load performed with memory_order_acquire which guarantees that the store to i will be visible in the second thread. Thus the assertion is guaranteed to hold.

On the other hand, if you use less strict memory orders then you don't get any guarantees.

-- thread 1 --
i.store(100,std::memory_order_relaxed);
signal.store(true,std::memory_order_relaxed);

-- thread 2 --
while(!signal.load(std::memory_order_relaxed));
int i2 = i.load(memory_order_relaxed);
// No guarantees about the value loaded from i!

Alternatively you can just use the default memory order which guarantees sequential consistency as long as you don't have any data races.

std::atomic<bool> signal(false);
int i = 0;

-- thread 1 --
i = 100;
signal = true;

-- thread 2 --
while(!signal);
assert(i == 100);