Skip to content
This repository has been archived by the owner on Dec 17, 2024. It is now read-only.

Move rest of the locks to SchedulerState #148

Merged
merged 2 commits into from
Mar 18, 2024
Merged

Move rest of the locks to SchedulerState #148

merged 2 commits into from
Mar 18, 2024

Conversation

tuommaki
Copy link
Contributor

Scheduler had at least one more deadlock hiding in it's code. Most probably it was the ProgramManager. Moving both, the mempool and program_manager to SchedulerState doesn't reveal the deadlock anymore.

`Scheduler` had at least one more deadlock hiding in it's code. Most
probably it was the `ProgramManager`. Moving both, the `mempool` and
`program_manager` to `SchedulerState` doesn't reveal the deadlock
anymore.
@tuommaki tuommaki requested a review from musitdev March 18, 2024 17:36
@tuommaki tuommaki self-assigned this Mar 18, 2024
@tuommaki
Copy link
Contributor Author

Going with this to get a build for devnet operators still today.

@musitdev Please still check the diff and give me a shout if you think there are any issues with this.

@tuommaki tuommaki merged commit 8476ea9 into main Mar 18, 2024
4 checks passed
@tuommaki tuommaki deleted the fix-deadlock branch March 18, 2024 19:07
@musitdev
Copy link
Contributor

I don't think that putting together the mutex will solve it. It just changes the probability to see it. We'll see in production, but it can be very annoying because silent deadlock become visible when the load increases.
I think the sooner we remove the mutex by re-architecting, the better it will be.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants