Prevent race condition in makeMonomialOrdering#4299
Conversation
A number of the variables used in this function are global, so we lock while modifying them so we can construct monomial orders in parallel.
|
I was planning on using this as an exercise in debugging :) |
| (t,t',value logmo, logmo)) | ||
| ret := (t,t',value logmo, logmo); | ||
| unlock makeMonomialOrderingMutex; | ||
| ret) |
There was a problem hiding this comment.
On my system, I've added a handy unlock(Mutex, Thing) := (M, x) -> ( unlock M; x ), so I can write:
unlock(makeMonomialOrderingMutex, (t,t',value logmo, logmo)))There was a problem hiding this comment.
Ooh, that's slick! Want to submit a PR to add it for everyone?
| -- If it's not a list, we'll make a list of one element from it. | ||
| if monsize === null then monsize = null; | ||
| if not isListOfIntegers degs then error "expected a list of integers"; | ||
| lock makeMonomialOrderingMutex; |
There was a problem hiding this comment.
can we add a keyword of the form
withLock lock codeThe idea here is you would do something like the following
withLock makeMonomialOrderingMutex (
ordering = {MonomialSize => monsize, ordering};
invert = inverses;
....
)And it would lock the mutex before the block and unlock the mutex no matter how we exit the block, otherwise we have to be careful about exceptions or returns.
There was a problem hiding this comment.
The Code object in the interpreter is unique. Why do we need to specify the additional label makeMonomialOrderingMutex here?
|
Closing in favor of #4367 |
3 participants
A number of the variables used in this function are global, so we lock while modifying them so we can construct monomial orders in parallel.
This also gives us a chance to use the new
Mutexclass!Before
After
Closes: #3239 (one of our greatest hits of GitHub workflow build failures!)
AI Disclosure
Claude Code zeroed in on what was causing
check(6, "NumericalImplicitization")to fail frequently and wrote an early draft of this commit.