Adar Dembo has posted comments on this change. ( http://gerrit.cloudera.org:8080/12112 )
Change subject: [util] use lighter locking scheme for ThreadMgr ...................................................................... Patch Set 1: (4 comments) http://gerrit.cloudera.org:8080/#/c/12112/1/src/kudu/util/thread.cc File src/kudu/util/thread.cc: http://gerrit.cloudera.org:8080/#/c/12112/1/src/kudu/util/thread.cc@165 PS1, Line 165: std::lock_guard<decltype(lock_)> l(lock_); Is this actually necessary? No other thread should have access to ThreadMgr while some thread is running its destructor. http://gerrit.cloudera.org:8080/#/c/12112/1/src/kudu/util/thread.cc@263 PS1, Line 263: std::lock_guard<decltype(lock_)> l(lock_); Why do we need this acquisition? http://gerrit.cloudera.org:8080/#/c/12112/1/src/kudu/util/thread.cc@346 PS1, Line 346: void ThreadMgr::PrintThreadDescriptorRow(const ThreadDescriptor& desc, DCHECK that lock_ isn't held? http://gerrit.cloudera.org:8080/#/c/12112/1/src/kudu/util/thread.cc@402 PS1, Line 402: "<h4>" << threads_running_metric_ << " thread(s) running" Doesn't this access need to be protected by lock_? BTW you might consider adding a unit test that starts/stop threads all while polling the web UI. I wonder if you could reuse PeriodicWebUIChecker for this. -- To view, visit http://gerrit.cloudera.org:8080/12112 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I4d49c1c39392e01c45019844430a4fe3d116c277 Gerrit-Change-Number: 12112 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Will Berkeley <[email protected]> Gerrit-Comment-Date: Wed, 19 Dec 2018 22:23:17 +0000 Gerrit-HasComments: Yes
