Page MenuHomePhabricator

[OpenMP][host runtime] Fix indirect lock table race condition

Authored by jlpeyton on Sep 13 2021, 2:42 PM.



The indirect lock table can exhibit a race condition during initializing and setting/unsetting locks.
This occurs if the lock table is resized by one thread (during an omp_init_lock) and accessed (during an
omp_set|unset_lock) by another thread.

The test runtime/test/lock/omp_init_lock.c test exposed this issue and
will fail if run enough times.

This patch restructures the lock table so pointer/iterator validity is
always kept. Instead of reallocating a single table to a larger size, the
lock table begins pre-allocated to accommodate 8K locks. Each row of the
table is allocated as needed with each row allowing 1K locks. If the 8K
limit is reached for the initial table, then another table, capable of
holding double the number of locks, is allocated and linked
as the next table. This double+linking process continues as needed. The indices
stored in the user's lock take this linked structure into account when
finding the lock within the table later on.

Diff Detail

Event Timeline

jlpeyton created this revision.Sep 13 2021, 2:42 PM
jlpeyton requested review of this revision.Sep 13 2021, 2:42 PM
hbae accepted this revision.Sep 16 2021, 4:47 PM


This revision is now accepted and ready to land.Sep 16 2021, 4:47 PM
This revision was landed with ongoing or failed builds.Sep 20 2021, 11:02 AM
This revision was automatically updated to reflect the committed changes.