When I am reading the slides, I am thinking what if we have a lot of threads. Do they have to communicate back and forth and proceed with caution? Does that hurt the performance?
anamdev
@Tengjiao I'm sure it does hurt performance, but it seems like something necessary to do for a correct solution. The optimistic example also does a check, but less frequently after every commit. In the end, both versions are dependent on how many conflicts exist. If there are fewer conflicts then the optimistic solution might be better for performance because fewer check messages are sent between threads. On the other hand, if there are a lot of conflicts, then the pessimistic detection might be better because you have less work to redo on conflict.
gogogo
What's the difference between stalling and aborting for case 2 (rd A)? Shouldn't they achieve the same results?
tommywow
Stalling allows the previous work to not get scarped and to be restarted. It saves some time and computation.
When I am reading the slides, I am thinking what if we have a lot of threads. Do they have to communicate back and forth and proceed with caution? Does that hurt the performance?
@Tengjiao I'm sure it does hurt performance, but it seems like something necessary to do for a correct solution. The optimistic example also does a check, but less frequently after every commit. In the end, both versions are dependent on how many conflicts exist. If there are fewer conflicts then the optimistic solution might be better for performance because fewer check messages are sent between threads. On the other hand, if there are a lot of conflicts, then the pessimistic detection might be better because you have less work to redo on conflict.
What's the difference between stalling and aborting for case 2 (rd A)? Shouldn't they achieve the same results?
Stalling allows the previous work to not get scarped and to be restarted. It saves some time and computation.