Alexey Serbin has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/14954 )

Change subject: [consensus] short-circuit response path for RequestVote()
......................................................................


Patch Set 3:

(4 comments)

http://gerrit.cloudera.org:8080/#/c/14954/3/src/kudu/consensus/raft_consensus.h
File src/kudu/consensus/raft_consensus.h:

http://gerrit.cloudera.org:8080/#/c/14954/3/src/kudu/consensus/raft_consensus.h@894
PS3, Line 894: reponsed
> responded to
Done


http://gerrit.cloudera.org:8080/#/c/14954/3/src/kudu/consensus/raft_consensus.h@921
PS3, Line 921:  this
             :   // field assigned only when 'lock_' is held.
> That aspect of the field's use is tangential to its synchronization, right?
Done.


http://gerrit.cloudera.org:8080/#/c/14954/3/src/kudu/consensus/raft_consensus.cc
File src/kudu/consensus/raft_consensus.cc:

http://gerrit.cloudera.org:8080/#/c/14954/3/src/kudu/consensus/raft_consensus.cc@198
PS3, Line 198:   DCHECK(std::atomic_is_lock_free(&withhold_votes_until_));
> Seems like this could be asserted at compile-time instead. Or not at all; i
Per this C++ reference, std::atomic<> might be implemented not via lock-free 
atomic CPU primitives, and only std::atomic_flag is guaranteed to be 
implemented using those:

  https://en.cppreference.com/w/cpp/atomic/atomic/is_lock_free

I wish it would be possible to have a simpler compile-time check instead of 
this, but such thing is available only starting C++17 (see 
std::atomic<T>::is_always_lock_free).

Probably, targeting only x86_64 architecture, we can safely drop this.  What do 
you think?


http://gerrit.cloudera.org:8080/#/c/14954/3/src/kudu/consensus/raft_consensus.cc@1671
PS3, Line 1671:     return RequestVoteRespondLeaderIsAlive(request, response);
> Should we recheck this condition after acquiring lock_ too?
I thought about this, and it seemed to me that it wouldn't make much 
difference.  The chances that a heartbeat from the leader arrives between 
checking for the condition here and later while under the lock.

I gave it a second thought, though.  I think it won't hurt to recheck for the 
condition under the lock again: it costs a little, but it helps to avoid extra 
elections and disruptive transfers of the leadership.



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

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I67efef72b74ce243ca060e89fcec6eb11e95e8e8
Gerrit-Change-Number: 14954
Gerrit-PatchSet: 3
Gerrit-Owner: Alexey Serbin <[email protected]>
Gerrit-Reviewer: Adar Dembo <[email protected]>
Gerrit-Reviewer: Alexey Serbin <[email protected]>
Gerrit-Reviewer: Kudu Jenkins (120)
Gerrit-Comment-Date: Mon, 30 Dec 2019 04:44:43 +0000
Gerrit-HasComments: Yes

Reply via email to