-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
create_scheduling_group / scheduling_group_key_create are not safe to run in parallel #2231
Comments
piodul
added a commit
to piodul/scylla
that referenced
this issue
May 9, 2024
Due to scylladb/seastar#2231, creating a scheduling group and a scheduling group key is not safe to do in parallel. The service level code may attempt to create scheduling groups while the cql_transport::cql_sg_stats scheduling group key is being created. Until the seastar issue is fixed, move initialization of the cql sg states before service level initialization. Refs: scylladb/seastar#2231
1 task
Makes sense. These are not data plane operations so can safely be serialized. |
piodul
added a commit
to piodul/scylla
that referenced
this issue
May 9, 2024
Due to scylladb/seastar#2231, creating a scheduling group and a scheduling group key is not safe to do in parallel. The service level code may attempt to create scheduling groups while the cql_transport::cql_sg_stats scheduling group key is being created. Until the seastar issue is fixed, move initialization of the cql sg states before service level initialization. Refs: scylladb/seastar#2231
denesb
pushed a commit
to scylladb/scylladb
that referenced
this issue
May 10, 2024
Due to scylladb/seastar#2231, creating a scheduling group and a scheduling group key is not safe to do in parallel. The service level code may attempt to create scheduling groups while the cql_transport::cql_sg_stats scheduling group key is being created. Until the seastar issue is fixed, move initialization of the cql sg states before service level initialization. Refs: scylladb/seastar#2231 Closes #18581
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I observed that running those two functions in parallel may lead to data of a scheduling group key initialized twice.
Those functions work like this:
create_scheduling_group
num_keys
variablenum_keys
scheduling_group_key_create
While I am not exactly sure what the sequence of events for my case was, looking at the implementation I think the following can happen:
num_keys
varPerhaps there might be other kinds of races. I think that operations like
create_scheduling_group
andscheduling_group_key_create
should be serialized.Relevant code:
seastar/src/core/reactor.cc
Lines 5016 to 5030 in d3657ec
seastar/src/core/reactor.cc
Lines 4859 to 4926 in d3657ec
The text was updated successfully, but these errors were encountered: