Todd Lipcon has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/9760 )

Change subject: meta_cache: improve multi-threaded scalability
......................................................................


Patch Set 1:

(4 comments)

http://gerrit.cloudera.org:8080/#/c/9760/1/src/kudu/client/meta_cache.h
File src/kudu/client/meta_cache.h:

http://gerrit.cloudera.org:8080/#/c/9760/1/src/kudu/client/meta_cache.h@261
PS1, Line 261:   std::atomic<bool> stale_;
> Previous discussion: https://gerrit.cloudera.org/c/1842/
Only thing i really dislike about std::atomic is that the API allows for 
Release_Load and Acquire_Store as follows:

std::atomic<int> x;
int v = x.load(std::memory_order_release);
x.store(v, std::memory_order_acquire);

... but it turns out that the C++ memory model prohibits such things from 
existing. Rather than crash or give a warning or somesuch, it silently allows 
them without emitting the memory barriers required by x86 (which are emitted by 
our own Release_Load and Acquire_Store macros). Granted, those two operations 
are somewhat more esoteric, but they're useful for various low-level things 
like seq-locks. It appears we only use them in a handful of places in Kudu and 
some of them are potentially not even correct usage :)

Anyway, I feel like we should probably move to std::atomic for most use cases, 
and perhaps see if we can write a clang-tidy checker for the above incorrect 
usages and contribute it upstream.


http://gerrit.cloudera.org:8080/#/c/9760/1/src/kudu/util/locks.h
File src/kudu/util/locks.h:

http://gerrit.cloudera.org:8080/#/c/9760/1/src/kudu/util/locks.h@142
PS1, Line 142: // Usage:
             : //   percpu_rwlock mylock;
             : //
             : //   // Lock shared:
             : //   {
             : //     boost::shared_lock<rw_spinlock> lock(mylock.get_lock());
             : //     ...
             : //   }
             : //
             : //   // Lock exclusive:
             : //
             : //   {
             : //     boost::lock_guard<percpu_rwlock> lock(mylock);
             : //     ...
             : //   }
> Mind updating this with the lock guards we actually use now?
Done


http://gerrit.cloudera.org:8080/#/c/9760/1/src/kudu/util/locks.h@142
PS1, Line 142: // Usage:
             : //   percpu_rwlock mylock;
             : //
             : //   // Lock shared:
             : //   {
             : //     boost::shared_lock<rw_spinlock> lock(mylock.get_lock());
             : //     ...
             : //   }
             : //
             : //   // Lock exclusive:
             : //
             : //   {
             : //     boost::lock_guard<percpu_rwlock> lock(mylock);
             : //     ...
             : //   }
> I think you missed this one.
sorry, my network crapped out mid-push and apparently I pushed an old version. 
take 2...


http://gerrit.cloudera.org:8080/#/c/9760/1/src/kudu/util/locks.h@239
PS1, Line 239:     rw_spinlock lock;
> Gotcha. Could you add a blurb about this optimization to the class comment?
Done



--
To view, visit http://gerrit.cloudera.org:8080/9760
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I38c8a94ea177bfa4f4e2048355464f76a5daa2ba
Gerrit-Change-Number: 9760
Gerrit-PatchSet: 1
Gerrit-Owner: Todd Lipcon <[email protected]>
Gerrit-Reviewer: Adar Dembo <[email protected]>
Gerrit-Reviewer: Alexey Serbin <[email protected]>
Gerrit-Reviewer: Dan Burkert <[email protected]>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <[email protected]>
Gerrit-Comment-Date: Thu, 29 Mar 2018 16:42:14 +0000
Gerrit-HasComments: Yes

Reply via email to