ensure reading a struct as a whole - c

Question

I have a shared struct variable between 2 threads:
struct {
long a;
long b;
long c;
} myStruct;
struct myStruct A;
All 3 fields of A is initialized to zero. Then 1st thread will update them:
A.a = 1;
A.b = 2;
A.c = 3;
And 2nd thread will read from it. What I want to ensure is that 2nd thread will read A as a whole, either the old value {0, 0, 0}, or the new value {1, 2, 3}, not some corrupted like {1, 2, 0}.
The struct don't fit in 64bit so I can not use builtin atomic of gcc, and I don't want to use mutex either, so I came up with 2 guarding flags:
struct {
long a;
long b;
long c;
volatile int beginCount, endCount;
} A;
then 1st thread will:
A.beginCount++;
A.a = 1;
A.b = 2;
A.c = 3;
A.endCount++;
and 2nd will loop until it get a consistent struct:
int begin, end;
myStruct tmp;
do {
begin = A.beginCount;
end = A.endCount;
tmp = A;
} while (!(begin == A.beginCount && end == A.endCount && A.beginCount == A.endCount))
// now tmp will be either {0,0,0} or {1,2,3}
Are those 2 guarding flags enough? If not then please point out the specificed combination of thread scheduling that could break it.
Edit 1: the reason I don't want to use mutex is that the 1st thread has high priority, it should not wait for anything. If 1st thread want to write when 2nd is reading, then 1st thread still write anyway, and 2nd thread has to redo the reading until it get a consistent value. We can't do that with mutex, at least not something I'm aware of.
Edit 2: about environment: this code run on multiprocessor system, and I dedicated 1 entire cpu core for each thread.
Edit 3: I know that synchronization without mutex or atomic is very tricky. I've listed down all combination I could think of, and could not find any one break the code. So, please, don't just tell that it won't work, I will really appreciated if you point out when it will break.

Answer 1

I don't want to use mutex either
On a uniprocessor system, if the first thread gets preempted while writing, the reading thread will spend its time slice spinning needlessly. You do want a mutex in such a case.
Both Linux futexes and Windows' CriticalSections don't context-switch in the non-contention case and on multiprocessor systems, spin a while before yielding.
Why reimplement the exact same mechanism?

Answer 2

There is absolutely no portable way to do what you want. Some very high-end systems have transactional memory that may be able to accomplish what you want, but the normal pattern for using transactional memory anyway is to write your code with locks and rely on the lock implementation to use transactions.
Simply use a mutex to protect both reads and writes. There is no other way to make your code correct, but lots of ways to make it "seem correct to testing" until it violates an invariant and crashes a few months later or gets run on a slightly different environment/cpu and starts crashing every time you run it.

Answer 3

My first advice is that you really should implement it using a mutex (be sure each thread holds the mutex for as little time as possible) and see if you actually run into any problems. Most likely you will find out that using a mutex works just fine, and that nothing more is required. Doing it that way has the advantage of being portable to any hardware, simple to understand, and easy to debug.
That said, if you insist on not using a mutex, then the only other option is to use atomic variables. Since atomic variables are word-sized, you won't be able to make an entire struct atomic, but you can fake it by instantiating an array of structs instead (the necessary size of the array will depend on how often you intend to update the struct) and then using atomic integers as indices into the "currently valid for reading" and "okay to write into for writing" structs in the array. Reading the current value of the struct out of the array is simple enough -- you just need to read from the "currently valid for reading" index in the array, which is guaranteed not to be written to -- but writing a new value is more elaborate; you need to atomically increment the "okay to write into for writing" index (and wrap it around if necessary to avoid indexing off the end of the array, and check for an overflow condition if, after doing this, the okay-for-writing index equals the read-from index). Then write your new struct into the slot specified by the okay-for-writing index. Then you've got to do an atomic compare-and-set operation to set the read-from index equal to the okay-for-writing index; if the compare-and-set operation fails, you need to restart the whole operation because another thread beat you to the update. Repeat the whole set() process again until the compare-and-set operation succeeds.
(if this all sounds dubious and error-prone, that's because it is. It can be implemented correctly, but it's very easy to instead implement it almost-correctly, and end up with code that works 99.999% of the time and then does something regrettable and non-reproducible the other 0.0001% of the time. Consider yourself warned :))