3 ms·

For 32bit or 64bit tagged pointer is there a big risk of version overflow?

• convolvatron 2y ago
  oh certainly. this is one of those slightly unsatisfactory consistency stories where its not a closed answer, its just arbitrarily unlikely that a conflict will arise. we've already got a _really_ small window where one thread has the old pointer and the other thread frees it, it goes through the heap, and is assigned the same address as the old version. now exponentiate the likelihood of that happening with the size of the tag space.
  • gpderetta 2y ago
    You just need to make it less likely than random RAM corruption:)
  • amluto 2y ago
    > we've already got a _really_ small window where one thread has the old pointer and the other thread frees it, it goes through the heap, and is assigned the same address as the old version Plenty of allocator implementations will do this, very efficiently, almost deterministically reusing the same address, if you free and then allocate something of similar size.
• Someone 2y ago
  There’s a risk, but far from a big one. You’d need exactly 2³² or even 2⁶⁴ pointer updates (or a multiple of it) between the time you read the pointer and the time you try writing it for running into problems. That’s not likely to be a problem even on a 1000-core CPU. So, technically, this isn’t solving the ABA problem, it’s just hiding it very, very well.