You don't modify the entire 64 bytes at the same time. That's why you fill it with atomic variables that you can modify _without_ locking. You need the array t

You don't modify the entire 64 bytes at the same time. That's why you fill it with atomic variables that you can modify _without_ locking. You need the array to contain structures that fill the cache line to avoid invalidation when two cores write/read structures close to each other. When two cores write/read to/from the same atomic variable in the same structure you of course need to know what the consequences will be, but most of the time it will only result on gliches and not crashes... say if the position of a player is updated by the physics and incoming network at the same time and read by the render core... the player will glitch to some location that might be wrong for the other writing core so you have to make sure that is handled to not behave in a non playable way, but performance on the CPU is the _only_ bottleneck we will ever have and we're already there. You could also look at Javas concurrency package. It's mostly atomic.