search

goraft / raft

UNMAINTAINED: A Go implementation of the Raft distributed consensus protocol.
MIT License
2.43k stars 480 forks source link

refactor(server.go) No lock is needed when reading server variables in a internal function #197

Closed xiang90 closed 10 years ago

xiang90 commented 10 years ago

Our server is a single routine for loop. We have a lock to avoid "data-race" between the external function calls(read/write) and internal operations(write). So we can drop the extra lock when reading variables internally.

xiang90 commented 10 years ago

/cc @benbjohnson @unihorn

benbjohnson commented 10 years ago

@xiangli-cmu Is this related to a bug? Does it pass the race detector? We need a lock around Server.peers since that can be read by the application.

xiang90 commented 10 years ago

@benbjohnson It is a cleanup. I tried test -race and these changes did not introduce more races and not fix any either.

I think the peer lock is not related to this pull request. This pull request does not change that behavior.

benbjohnson commented 10 years ago

@xiangli-cmu If you call Server.Peers() while updateCurrentTerm() is messing with the peers then you'll get a race error. We need the lock around there.

xiang90 commented 10 years ago

can i merge this one? i will try to fix data race after this.

benbjohnson commented 10 years ago

@xiangli-cmu Sure. Go for it. Check it against the etcd functional tests with -race set on the tests and on the build.