While going through the cc.cu file of Lonestar, I noticed a few races, which I note below.
Line 257
index_type x = edge_src[edge];
index_type y = graph.getAbsDestination(edge);
index_type mx = x > y ? x : y;
index_type mn = x > y ? y : x;
-> graph.node_data[mx] = mn;
Explanation:
Multiple edges can have the same value for mx.
Assigning mn to that node will then create a race.
This can be avoided by using a CAS operation on graph.node_data[mx] which checks if the data is unset, and only sets to mn in that case.
One thread may be reading graph.node_data[p_u] while another node is assigning graph.node_data[node] = p_v leading to a race. Since the assignment is through a normal store operation, it may also end up getting cached, and not visible to the thread reading the node_data.
While going through the cc.cu file of Lonestar, I noticed a few races, which I note below.
Line 257
Explanation: Multiple edges can have the same value for mx. Assigning mn to that node will then create a race. This can be avoided by using a CAS operation on graph.node_data[mx] which checks if the data is unset, and only sets to mn in that case.
Line 343 and 346
One thread may be reading graph.node_data[p_u] while another node is assigning graph.node_data[node] = p_v leading to a race. Since the assignment is through a normal store operation, it may also end up getting cached, and not visible to the thread reading the node_data.
Lines 311, 312, 321
Similar to the first case.