I wonder if there are any downsides to this particular approach. For one, it seems like every compare_and_swap wants to have exclusive read access to &prev;->next, wouldn't this cause significant traffic on the interconnect and thrashing in the caches?
BigFish
@yue1 Yes, I think this may be a problem as we met in assignment 3 to implement BFS using compare_and_swap.
gryffolyon
Also there is no bounded waiting here at all. A thread can continuously fail each time while other make progress leading to its starvation
MediumPepsi
I'm wondering why it's necessary to search for "after" from hear of the list? Can we just use one level of while loop?
haodongl
@MediumPepsi I think it's because we need to search from the head for the position to insert our new node, and in this case it's node "after" we are searching for.
I wonder if there are any downsides to this particular approach. For one, it seems like every compare_and_swap wants to have exclusive read access to &prev;->next, wouldn't this cause significant traffic on the interconnect and thrashing in the caches?
@yue1 Yes, I think this may be a problem as we met in assignment 3 to implement BFS using compare_and_swap.
Also there is no bounded waiting here at all. A thread can continuously fail each time while other make progress leading to its starvation
I'm wondering why it's necessary to search for "after" from hear of the list? Can we just use one level of while loop?
@MediumPepsi I think it's because we need to search from the head for the position to insert our new node, and in this case it's node "after" we are searching for.