同步访问变量

Question

I need to provide synchronization to some members of a structure.
If the structure is something like this

struct SharedStruct {
    int Value1;
    int Value2;
}

and I have a global variable

SharedStruct obj;  

I want that the write from a processor

 obj.Value1 = 5; // Processor B

to be immediately visible to the other processors, so that when I test the value

 if(obj.Value1 == 5) { DoSmth(); } // Processor A
 else DoSmthElse();   

to get the new value, not some old value from the cache.
First I though that if I use volatile when writing/reading the values, it is enough. But I read that volatile can't solve this kind o issues.
The members are guaranteed to be properly aligned on 2/4/8 byte boundaries, and writes should be atomic in this case, but I'm not sure how the cache could interfere with this.
Using memory barriers (mfence, sfence, etc.) would be enough ? Or some interlocked operations are required ?
Or maybe something like

lock mov addr, REGISTER  

?
The easiest would obviously be some locking mechanism, but speed is critical and can't afford locks :(

Edit
Maybe I should clarify a bit. The value is set only once (behaves like a flag). All the other threads need just to read it. That's why I think that it may be a way to force the read of this new value without using locks.

Thanks in advance!

Answer 1

There Ain't No Such Thing As A Free Lunch. If your data is being accessed from multiple threads, and it is necessary that updates are immediately visible by those other threads, then you have to protect the shared struct by a mutex, or a readers/writers lock, or some similar mechanism.

Performance is a valid concern when synchronizing code, but it is trumped by correctness. Generally speaking, aim for correctness first and then profile your code. Worrying about performance when you haven't yet nailed down correctness is premature optimization.

Answer 2

All the other answers here seem to hand wave about the complexities of updating shared variables using mutexes, etc. It is true that you want the update to be atomic. And you could use various OS primitives to ensure that, and that would be good programming style.

However, on most modern processors (certainly the x86), writes of small, aligned scalar values is atomic and immediately visible to other processors due to cache coherency. So in this special case, you don't need all the synchronizing junk; the hardware does the atomic operation for you. Certainly this is safe with 4 byte values (eg, "int" in 32 bit C compilers).

So you could just initialize Value1 with an uninteresting value (say 0) before you start the parallel threads, and simply write other values there. If the question is exiting the loop on a fixed value (eg, if value1 == 5) this will be perfectly safe.

If you insist on capturing the first value written, this won't work. But if you have a parallel set of threads, and any value written other than the uninteresting one will do, this is also fine.

Answer 3

I second peterb's answer to aim for correctness first. Yes, you can use memory barriers here, but they will not do what you want.

You said immediately . However, how immediate this update ever can be, you could (and will) end up with the if() clause being executed, then the flag being set, and than the DoSmthElse() being executed afterwards. This is called a race condition...

You want to synchronize something, it seems, but it is not this flag.

Answer 4

Use explicitly atomic instructions. I believe most compilers offer these as intrinsics. Compare and Exchange is another good one.

If you intend to write a lockless algorithm, you need to write it so that your changes only take effect when conditions are as expected.

For example, if you intend to insert a linked list object, use the compare/exchange stuff so that it only inserts if the pointer still points at the same location when you actually do the update.

Or if you are going to decrement a reference count and free the memory at count 0, you will want to pre-free it by making it unavailable somehow, check that the count is still 0 and then really free it. Or something like that.

Using a lock, operate, unlock design is generally a lot easier. The lock-free algorithms are really difficult to get right.

Answer 5

Making the field volatile should make the change "immediately" visible in other threads, but there is no guarantee that the instant at which thread A executes the update doesn't occur after thread B tests the value but before thread B executes the body of the if/else statement.

It sounds like what you really want to do is make that if/else statement atomic, and that will require either a lock, or an algorithm that is tolerant of this sort of situation.