Fix a data race in TestEvictMultiple detected by go test -race.
There were a few places where we locked stateMu before accessing State
and a few places where we didn't.
The State implementation from database/sinkdb does its own locking,
so this wasn't a real race in Chain Core, only in tests using the
net/raft state implementation.
We could remove the net/raft's mutex altogether if it weren't for two
things:
the ConfState stored on Service that needs to be updated every time
the raft configuration changes
the stateCond condition variable used for waiting until applyEntry
changes the state
This change
adds a mutex to the net/raft test state
documents that the State interface must be safe for concurrent access
adds a new confMu mutex for protecting the ConfState
removes all unnecessary uses of stateMu outside of the condition
variable
renames stateMu/stateCond to applyMu/applyCond to reflect that it's
now only used for the applyEntry condition variable and not for
protecting the state
An alternative to this approach could be to always lock stateMu before
accessing State, but that would add unnecessary locking because sinkdb's
State requires its own locking regardless.
Fix a data race in TestEvictMultiple detected by
go test -race. There were a few places where we locked stateMu before accessing State and a few places where we didn't.The State implementation from database/sinkdb does its own locking, so this wasn't a real race in Chain Core, only in tests using the net/raft state implementation.
We could remove the net/raft's mutex altogether if it weren't for two things:
This change
An alternative to this approach could be to always lock stateMu before accessing State, but that would add unnecessary locking because sinkdb's State requires its own locking regardless.