3 ms·
Something not mentioned there is locking. For the specific use case (timestamps) that the OP wants, it might not be important, but for many common use cases, li
by joosters 11y ago
Something not mentioned there is locking. For the specific use case (timestamps) that the OP wants, it might not be important, but for many common use cases, like 64 bit counters, you can suddenly hit consistency problems in programs. I think that older x86 processors couldn't atomically write 64 bit numbers, so you might have to add locks around all the accesses. This could be a huge performance hit.
ISTR this was a problem for Linux kernels? There used to be several kernel counters that were stuck at 32 bits because the overhead of making them 64 bits was just too much. I think one example was network byte counters for NICs? I might be misremembering this, though.
- nickpsecurity 11y agoIt's tricky. There's some interesting comments and issues mentioned here: https://stackoverflow.com/questions/5162673/how-to-read-two-32bit-counters-as-a-64bit-integer-without-race-condition# https://stackoverflow.com/questions/5162673/how-to-read-two-...
- quincunx 11y agoThe x86 instruction for this would be LOCK CMPXCHG8B and would allow atomically writing 64 bits. (The x64 version would be LOCK CMPXCHG16B for writing 128 bits.) Instruction goes back a while, there was a bug on pentium https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug
- qb45 11y agoYep, but first you have to load this counter and increment it manually in some CPU register. And you also need to repeat the whole sequence in case CMPXCHG8B fails. With 32 bit integers you just execute XADD and move on with your life.