Skip to content

Move locking operations onto the module's thread #2866

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Jul 14, 2025
Merged

Conversation

jsdt
Copy link
Contributor

@jsdt jsdt commented Jun 13, 2025

Description of Changes

This branch moves a lot of code from blocking threads onto the module thread. A common pattern was using asyncify to spawn a blocking task, which would then grab a db-level lock and do some work. This change introduces the on_module_thread function on ModuleHost, which runs a function on the module thread (which was previously only used for reducer calls). The code inside is largely unchanged, so there are still locks used to guard access to things, but there should be less contention on them.

This does limit some potential concurrency, since operations that only grab a shared lock are now serialized. In practice, this shouldn't be a big regression, since the locks we are using stop giving out shared locks as soon as one writer shows up.

The only real benefits to this PR are:

  1. Queue wait time stats are more comprehensive (since they include subscription operations).
  2. We will have fewer blocking threads, which should help reduce context switching.

I think it moves toward a simplified concurrency model, where all module operations are sent to a single actor, but there are a lot more changes needed to get there.

Expected complexity level and risk

2

Testing

We have done some bot testing on a version of this, but unit testing it is not really feasible.

@jsdt jsdt assigned gefjon and unassigned jsdt Jul 8, 2025
@jsdt jsdt requested a review from gefjon July 8, 2025 16:12
@jsdt jsdt marked this pull request as ready for review July 8, 2025 16:12
@bfops bfops added performance A PR/Issue related to improving performance of stdb release-any To be landed in any release window labels Jul 14, 2025
@jsdt jsdt added this pull request to the merge queue Jul 14, 2025
Merged via the queue into master with commit 666ade7 Jul 14, 2025
29 of 30 checks passed
@Centril Centril deleted the jsdt/single-threading branch July 15, 2025 13:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance A PR/Issue related to improving performance of stdb release-any To be landed in any release window
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants