[SERVER-30838] Remove "_inlock" function name usage Created: 25/Aug/17  Updated: 26/Feb/18

Status: Open
Project: Core Server
Component/s: Concurrency, Querying, Replication, Sharding
Affects Version/s: None
Fix Version/s: Backlog

Type: Improvement Priority: Major - P3
Reporter: Nathan Myers Assignee: Backlog - Platform Team
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
is related to SERVER-30748 Alternative to '_inlock' function naming Closed


The server has 1228 mentions of "_inlock" functions in 133 files, including declarations, calls, and comments. These mentions should be transitioned to take/pass a mongo::WithLock argument, instead, as defined in util/concurrency/with_lock.h, to improve static error detection.

Adoption can be incremental, per function, per file, or per subsystem. Because usage of the "*_inlock" naming convention is primarily confined to private member functions, uses of any particular such name are confined to a few files, most commonly two.

In any case, no new "_inlock" functions should be created.

Comment by Eric Milkie [ 25/Aug/17 ]

It sounds like there are two separate work items suggested by the description of this ticket: remove all current uses of _inlock, and prevent new uses of _inlock. Should these be separate tickets?

Comment by Nathan Myers [ 25/Aug/17 ]

I didn't see a way for preventing new uses to be a work item, beyond posting an announcement somewhere for the information of code reviewers. Is there a way to instrument lint to do that?

Comment by Eric Milkie [ 25/Aug/17 ]

There could very well be, but I am not personally aware of it.

Comment by Githook User [ 25/Sep/17 ]


{'email': 'nathan.myers@10gen.com', 'name': 'Nathan Myers', 'username': 'nathan-myers-mongo'}

Message: SERVER-30838 Remove _inlock names in sharding subsystem
Branch: master

Comment by Nathan Myers [ 25/Sep/17 ]

push d7aca6435e8 above does everything under mongo/s/. Everything under db/s was done by the original patch for SERVER-30748 (push 529d5de7)

Generated at Fri Oct 19 08:00:14 UTC 2018 using Jira 7.12.1#712002-sha1:609a50578ba6bc73dbf8b05dddd7c04a04b6807c.