Possible bug in listings 7.4-5

[ulatekh]

I could be wrong about this, but I thought it better to ask a stupid question & learn from it.

If one thread gets suspended (or there's a cache-miss or something) in pop() between testing if old_head isn't nullptr, and the compare/exchange with head/old_head/old_head->next, and another thread succeeds in its compare/exchange with chain_pending_nodes() as called by chain_pending_node() as called by try_reclaim() when threads_in_app != 1 ... then couldn't the stack get replaced by the list of to-be-deleted nodes?

If the compare/exchange in pop() doesn't begin until the thread resumes, then I don't think it won't detect that old_head->next has changed.

The solution, I believe, would be to have a separate node* next_free in struct node.

[ulatekh]

I think I figured it out...even though old_head->next could be part of the to-be-deleted chain, the compare/exchange with head/old_head/old_head->next that refers to it wouldn't succeed because, by then, head would have changed.