From my understanding, in this case, we do not need to impose constraints on the number of readers or writers accessing the stack at the same time like the last couple of slides on queue implementations. In this case, the atomic compare and swap will detect a change in the top of the stack and prevent a thread from popping or pushing the top if another thread changed the top of the stack. Does this mean we can do use compare and swap for queue implementation and remove the single reader single writer constraint?

Besides the ABA problem, could something happen between compare_and_swap(&s->top, old_top, new_top) == old_top evaluating to true, and the statement return old_top, such as another thread popping or pushing, to make the result incorrect?

@blipblop Once compare_and_swap evaluates to True, the function has already performed its "work", i.e. popping off old_top and setting the top of the stack to new_top. It's true that some other thread can come in and modify the stack further, but this thread has achieved what it promised to achieve.