Concern about AtomicOption

[nanokatze]

Hello,

I'm concerned with regard to AtomicOption type. On weak architectures, consider the following:

let a = Arc::new(AtomicOption::new());
// CPU 0
// The box is visible to current CPU but not to others yet.
a.swap_box(box [0; 0xffff], Relaxed);
// CPU 1
// Pointer is now visible but the contents of box might be not.
a.take(Relaxed);

CPU 0 puts box in the AtomicOption using Relaxed order, and within a few moments, once it is visible, CPU 1 takes it. What we should end up with is CPU 1 with a pointer to potentially invalid memory, because the contents in memory that the pointer points to, which have just been written to by CPU 0 might not be visible to CPU 1 yet. I expect that with AcquireRelease barrier at swap and Acquire barrier at take, when used together with Relaxed swap itself make AtomicOption correct.

I'm by no means expert in this area, so, if I'm wrong, explanation as to why AtomicOption is correct even without barriers would be appreciated.

Your reasoning is correct - the implementation of AtomicOption is unsound.

We should really get rid of it and rethink how to provide a nice package of extended atomic types. There was some discussion on that topic here.

[jeehoonkang]

Thank you for finding this bug! I agree with your suggestion: using AcqRel for swap and Acquire for take.