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

fix(locations): make source info access concurrent safe #1433

Merged
merged 3 commits into from
Sep 23, 2024

Conversation

noahdietz
Copy link
Collaborator

@noahdietz noahdietz commented Sep 23, 2024

Refactors internal source code info registry for the locations package to leverage a synx.Mutex in protecting the maps containing the descriptor/path to SourceCodeInfo pairs. Uses the "mutex hat" pattern for naming/commenting.

Adds a simple concurrency test to run with -race. Note: Running this same test on main produced the data race warning.

Executes unit tests in CI with the -race flag.

Updates #1430

locations/locations.go Outdated Show resolved Hide resolved
@noahdietz noahdietz marked this pull request as ready for review September 23, 2024 19:06
@noahdietz noahdietz requested a review from a team as a code owner September 23, 2024 19:06
@noahdietz noahdietz added the automerge Summon MOG for automerging label Sep 23, 2024

// findLocation returns the Location for a given path.
func (si sourceInfo) findLocation(path []int32) *dpb.SourceCodeInfo_Location {
func (si *sourceInfo) findLocation(path []int32) *dpb.SourceCodeInfo_Location {
si.infoMu.Lock()

Choose a reason for hiding this comment

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

Do we need to lock on the read of this map? It seems like we will only write the contents of the info map once per key, and I assume we only try to access it after writing, so there shouldn't be a need to lock on read

I could only see a lock being needed if the call to findLocation can happen while another call to sourceInfo() is currently executing and writing the value for that location

Not that it matters too much to have an extra lock call 🤷‍♀️

Copy link
Member

Choose a reason for hiding this comment

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

I think tooling such as the test -race flag might complain without the read lock, but I guess you can remove it to see if that happens.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I could only see a lock being needed if the call to findLocation can happen while another call to sourceInfo() is currently executing and writing the value for that location

Not that it matters too much to have an extra lock call 🤷‍♀️

Yeah that's what I'm being cautious about - i'd rather just synchronize all access. It's not performant enough of an application to really care about the extra lock call and I'm choosing to go one step short of using sync.Map (which is not strongly typed) :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks @slevenick for the point/question though

@noahdietz noahdietz merged commit 223aa5b into googleapis:main Sep 23, 2024
6 checks passed
@gcf-merge-on-green gcf-merge-on-green bot removed the automerge Summon MOG for automerging label Sep 23, 2024
@noahdietz noahdietz deleted the concurrent-locations branch September 23, 2024 19:28
gcf-merge-on-green bot pushed a commit that referenced this pull request Sep 23, 2024
🤖 I have created a release *beep* *boop*
---


## [1.67.3](https://togithub.com/googleapis/api-linter/compare/v1.67.2...v1.67.3) (2024-09-23)


### Bug Fixes

* **AIP-132:** refine List request response regex ([#1420](https://togithub.com/googleapis/api-linter/issues/1420)) ([5cc4d27](https://togithub.com/googleapis/api-linter/commit/5cc4d279c9cfc80545a9d2447b4fe13a8032b2aa))
* **AIP-136:** ignore revision methods ([#1432](https://togithub.com/googleapis/api-linter/issues/1432)) ([a6ba5f3](https://togithub.com/googleapis/api-linter/commit/a6ba5f32458cefc42b662019d97199d0a8e86551))
* **AIP-162:** handle LRO in response name rules ([#1431](https://togithub.com/googleapis/api-linter/issues/1431)) ([8bca1dd](https://togithub.com/googleapis/api-linter/commit/8bca1dd68ccf00c39a06da9862ac8c599029297e))
* **internal/utils:** refine Get, Create, Update, Delete request regex ([#1422](https://togithub.com/googleapis/api-linter/issues/1422)) ([487328c](https://togithub.com/googleapis/api-linter/commit/487328ca8708521562be2921d3c4f2aabaf8a5ae))
* **locations:** make source info access concurrent safe ([#1433](https://togithub.com/googleapis/api-linter/issues/1433)) ([223aa5b](https://togithub.com/googleapis/api-linter/commit/223aa5bb6cf4f24193ad6c6037e1b88160474f2e))


### Documentation

* **AIP-132:** fix incorrect field for AIP-217 ([#1423](https://togithub.com/googleapis/api-linter/issues/1423)) ([6a52a68](https://togithub.com/googleapis/api-linter/commit/6a52a6845bf8f240a4d9f9a305a26609a2699c17))
* **AIP-134:** change mandated to recommended ([#1426](https://togithub.com/googleapis/api-linter/issues/1426)) ([338b6a9](https://togithub.com/googleapis/api-linter/commit/338b6a95906b61ba5a83805bce92919dd53725dc))

---
This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants