Skip to content
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

Name all util/mutexes #16975

Merged
merged 2 commits into from
Mar 14, 2024
Merged

Conversation

travisdowns
Copy link
Member

Certain structures like semaphore and mutex can be "named" which is
useful to identify a particular structure in log messages, exceptions
or just about anything you can imagine.

When we added support for named mutexes, we did not give names to all
existing mutexes, perhaps because there are a lot of them: the
unnamed version of the constructor was left and removing it was
left as a TODO.

This series crosses that TODO off the list and names all existing
mutexes that weren't already named and removes the unnamed
constructor.

See also #5489.

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v23.3.x
  • v23.2.x

Release Notes

  • none

@github-actions github-actions bot added area/redpanda area/wasm WASM Data Transforms labels Mar 8, 2024
@travisdowns travisdowns changed the title Td name all mutexes Name all util/mutexes Mar 8, 2024
@travisdowns
Copy link
Member Author

travisdowns commented Mar 8, 2024

This sort of came up in the spike investigation, where it was useful to have named mutexes in order to report generically when a certain mutex had a wait that exceeded a given threshold. This change doesn't actually include that kind of logging or anything but as I side effect I decide to name all mutexes and cross that TODO off the list.

The entirety of the first change is just naming mutexes. The second change removes the default constructor which allows the creation of unnamed (well, named "mutex") mutexes.

@BenPope
Copy link
Member

BenPope commented Mar 8, 2024

See also #6330

@travisdowns
Copy link
Member Author

@BenPope - ah, I hadn't seen that one.

Do you think I should pull in some or all of that? Aaron had chosen different names in some places and definitely went a bit further with dynamic naming, e.g., naming based on the ntp in places where the mutex is ntp-specific.

@BenPope
Copy link
Member

BenPope commented Mar 8, 2024

@BenPope - ah, I hadn't seen that one.

Do you think I should pull in some or all of that? Aaron had chosen different names in some places and definitely went a bit further with dynamic naming, e.g., naming based on the ntp in places where the mutex is ntp-specific.

I never got round to reviewing it, so I can't be sure. I'm happy to have you make the call, you have most context here, especially if you've taken a look at the PR I linked!.

StephanDollberg
StephanDollberg previously approved these changes Mar 8, 2024
Copy link
Member

@StephanDollberg StephanDollberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel like the naming is inconsistent in a couple places but it's good for searching either way.

@@ -315,7 +315,7 @@ class disk_log_impl final : public log {
model::offset _start_offset;
// Used to serialize updates to _start_offset. See the update_start_offset
// method.
mutex _start_offset_lock;
mutex _start_offset_lock{"disk_log_impl::start_offset_lock"};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reasoning why some names have the class name in them while others don't?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I sort of evolved my strategy over time. My overall thought was "it doesn't matter too much as these are going to be searched", but what I settled on was mostly: use class name::member name except in places where a class just had some single general mutex in which case I sometimes just used the class name. Also strip the leading _. Also remove "mutex" or "lock" for things named like foo_mutex or foo_lock.

I think most of the cases that "don't have class name" are actually cases where I only used the class name, and not the member name?

I'm fine to do anything really to get this in: if you suggest a strategy I will redo the change following that strategy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also toyed with using std::source_location to keep the default constructor around and name the mutex based on say dir/file.cc:LINE but that seems mostly worse I think (if you're willing to do the work to rename them all).

Copy link
Member

@BenPope BenPope Mar 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I also immediately thought source_location, but then, there's a lot more useful info that could be added and it doesn't gain much over a name. I wouldn't block an improvement in the pursuit of the perfect bike-shed, though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to merge as is.

BenPope
BenPope previously approved these changes Mar 12, 2024
Copy link
Member

@BenPope BenPope left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A vast improvement.

@emaxerrno
Copy link
Contributor

@travisdowns wondering if we just remove mutex by putting the only mutex in the ss:: ns forcing a ctor named param

@travisdowns
Copy link
Member Author

@emaxerrno wrote:

@travisdowns wondering if we just remove mutex by putting the only mutex in the ss:: ns forcing a ctor named param

Currently there is no ss::mutex - this class is purely on our side. So in this series I have removed the unnamed ctor so after this goes in everybody will be forced to use the named constructor as you suggest.

Does that address your feedback or did I misunderstand?

Name all mutexes that are not already named as precursor to removing
the unnamed constructor from utils/mutex (see next change for
additional details and reasoning).
Certain structures like semaphore and mutex can be "named" which is
useful to identify a particular structure in log messages, exceptions
or just about anything you can imagine.

When we added support for named mutexes, we did not give names to all
existing mutexes, perhaps because there are a lot of them: the
unnamed version of the constructor was left and remove it was
left as a TODO.

This change crosses that TODO off the list and removes the unnamed
constructor (the prior change in this series named all existing
mutexes that weren't already named).

Issue redpanda-data#5489.
@vbotbuildovich
Copy link
Collaborator

vbotbuildovich commented Mar 14, 2024

@travisdowns travisdowns merged commit 3647fca into redpanda-data:dev Mar 14, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/redpanda area/wasm WASM Data Transforms
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants