-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: rewrite sequences of mutex calls #41253
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
Comments
Does that ever happen? Is it worth optimizing?
That's a neat trick to detect starvation. Not sure it is worth baking into the compiler, though. Maybe we can just detect |
Surprisingly, as I would have expected Unlock/Lock instead, Lock/Unlock is the pair that happens most frequently in the wild (at least according to the BQ GitHub dataset; see first post for the query used):
Will try some experiments to see how much things improve. It is true that all of these are pretty niche use cases though. Before running those BQ queries my main argument here was that if we add the Unlock/Lock machinery it would be trivial (and less surprising?) to add also the Lock/Unlock one.
I think it's ok to proceed incrementally, even though we'd be leaving some performance wins on the plate. Hopefully for things like these the potential inlining benefit, once the register-based calling convention lands, should be pretty low. |
Hm, I checked the first three results from that query. The first is just testing performance of Lock/Unlock itself. The second says this:
Not sure at all what that means. The third is just an assert that locks aren't already held:
Not sure any of these are worth optimizing. |
I see this pattern generally (correctly or not) as a way to indicate that a number of concurrent goroutines have finished processing their work. For example, https://github.com/twmb/kafka-go/blob/master/pkg/kgo/broker.go#L145 (In this particular case this is an RWMutex, so I the goroutines with their RLocks finish, then the writer's Lock() is allowed to happen. Maybe there's no good reason if it's a regular Mutex and not a RWMutex?) staticcheck detects and complains about empty critical sections. |
Just a random idea that may be worth considering. It should be safe (at least on amd64) for the compiler to rewrite sequences of
to
and, similarly,
to
Especially the latter is used in low-priority long-running operations holding a mutex to yield to higher-priority operations, like:
(that ideally should instead be written as follows, but that would require a much smarter compiler)
The benefit being that, in the no-contention case, we would avoid two RMW atomic ops and replace it with a single atomic load from a location that is almost certainly already in cache, plus a predictable jump (in the contention case the extra load+jump would be overshadowed by the rest of the mutex machinery, so it shouldn't matter anyway). I haven't benchmarked this yet: I can do it if we're interested in adding this.
A (imperfect) search on the the GH dataset on BQ shows the following number of occurrences:
query
The text was updated successfully, but these errors were encountered: