Open eszpotanski opened 2 weeks ago
@jjcherry56 Do these changes seem reasonable, or is there a better way to address these data races? The atomic bitset seems a bit complicated to me, but it might be worth the speed up.
As https://github.com/parallaxsw/OpenSTA/commit/b4be3c537af174eb3d6e486c8f1371882562e631 fixed part of the data races, I've updated this PR to contain fixes for remaining ones - caused by:
This PR fixes following data races found by ThreadSanitizer when OpenSTA is run by OpenROAD-flow-scripts:
Accessing tags_ and taggroups in sta::Search while they're being reallocated in another thread. It's not enough to delay the swap, as reading from an array is two operations on x86 (load the pointer, then load the array element). The array may get swapped out and freed in between those. Example warning:
Accessing and modifying bit fields from multiple threads. It's not possible to write individual bits to RAM, the best you can do is read a byte, do a bit operation on it, and write it back. Moreover, compilers can (and do) read up to 8 bytes, do bit operations on that, and write the whole 8 bytes back. If between reading and writing a field we're not even accessing (seemingly) changes, then the write-back overwrites that change. Example warning:
Indexing and inserting in an ObjectTable or ArrayTable in sta::Graph from multiple threads. Example warning:
A race between PathGroup::savable which accesses PathEnds and PathGroup::prune() which deletes PathEnds. Example warning:
These changes incur a significant slowdown (between 10% and 40%, depending on number of threads, used design or stage).
Note that these are only the races found by ThreadSanitizer, not necessarily all of them.