This is the mechanism that I had in mind. It's actually a really good one if you have lots of concurrent reads and few writes because there isn't going to be any cacheline ping pong. With a more traditional read-write lock, even the readers write to the cacheline holding the lock, and that's a shared cacheline so it's going to ping pong around. By contrast, the generation counter is read-only to readers.
But consider: the generation counter effectively acts as a lock that locks out reader threads while the update takes place. It also serves to lock out other writer threads.
So yes, one can call that "lock-free" if one really wants to, but I find it more honest to just admit that it's a custom lock with custom properties.
It's not lock-free, it's wait-free and therein lies the problem. The reader thread(s) are not locked out - they are free to continue running, endlessly looping waiting for the moment when they can consistently read the pseudo-atomic data. That's quite different behavior than if they used a lock, which they would find already held, and they would sleep.
But it is not wait-free, not even non blocking; if I understand your model correctly, a writer blocked in the right moment will prevent a reader to make progress exactly as you described.
Edit: with double buffering I guess it would be lock free, but still not wait free as a fast producer can still starve consumers indefinitely.
Neither writer nor reader needs to block. The writer does CAS on the generation counter to ensure it is safe against other writer threads. The reader just spins until it reads the same generation counter value before and after the read.
What happens if a writer halts in the middle of a write? How the reader can ever complete a consistent read?
With double buffering the reader can always fall back on the other buffer (hence it is lock-free, assuming somehow that writers always agree on the current write buffer), but then a fast writer can always prevent a slow reader from reading a consistent timestamp in a row which means it is not wait free.
But consider: the generation counter effectively acts as a lock that locks out reader threads while the update takes place. It also serves to lock out other writer threads.
So yes, one can call that "lock-free" if one really wants to, but I find it more honest to just admit that it's a custom lock with custom properties.