Provenance is a hard problem, so I'm probably missing something here
Provenance is a hard problem, so I'm probably missing something here
Posted Oct 7, 2025 18:34 UTC (Tue) by daroc (editor, #160859)In reply to: Provenance is a hard problem, so I'm probably missing something here by NYKevin
Parent article: Progress on defeating lifetime-end pointer zapping
Bearing in mind that I am not an expert, there are existing atomic non-compare-and-swap ways to synchronize between threads, in the form of relaxed writes/reads. In fact, imagine the following scenario involving an implementation of hazard pointers:
Thread 1 reads a pointer to A from the top of the linked list, and is then immediately preempted. Thread 2 pops from the list, frees A, allocates B in the same location, and pushes B. Now the pointer that thread 1 holds is a 'zombie' with the wrong provenance.
Now thread 1 writes the zombie pointer into its hazard-pointer list, instructing other threads not to free the referent of the pointer. Then it does a relaxed read of the top of the linked list, and checks that the list hasn't changed.
Now thread 1 thinks that it has a valid pointer and A can't be freed. But actually it has a pointer to B with the wrong provenance. The other threads won't free B, because there is a pointer to it in thread 1's hazard table, so thread 1 really is safe to operate on B. But if the compiler notices that the provenance is wrong, it could say this is undefined behavior. At no point was a compare-and-swap operation involved, but (I believe) if thread 1 hadn't been preempted at that exact moment, the whole scenario would be legal.
It's possible that I've missed some detail — provenance and concurrency are tricky — but I suspect that is the kind of more complex scenario that needs full angelic provenance to handle.