为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：master分支
- 【问题描述】：
我不确定提到这里是否合适，如果不合适麻烦告知应该发在哪，多谢。
我在github titan上提了一个issue，主要是想交流、确认下我分析的情况是否会是一个bug。
场景是我看到当Titan在LogAndApply VersionEdit失败后，会让titan进入read only状态，此时主要是通过设置bg_error_以及has_bg_error_这个flag。 后续接口调用上，都会判断has_bg_error_是否为true，进而在为true是，阻止用户的后续put/write操作。
但是代码实现上， has_bg_error_的判断逻辑（HasBGError()）中，并没有hold锁来判断has_bg_error_，而是直接依靠has_bg_error_的原子性来完成，has_bg_error_自身的原子性是没有问题的， 但我想到的场景是，因为HasBGError()判断时，没有hold锁，当LogAndApply实际已经失败，且bg_error_已经被设置，但是has_bg_error_还没来得及设置，此时，HasBGError()仍然会返回false，进而，用户方的Put/Write会被放过，继续执行，而如果此时进一步的引起Compaction，出发后续的BlobFileSet上的LogAndApply，则会使得在一个已经出错的状态下，进一步apply错误的信息， 进而导致一些非预期的行为
LogAndApply失败，可能是manifest写入出了问题，此时，可能writer已经设置为error了，此时还好说，如果是VersionStorage上的一些校验出问题，例如stoarge->MarkFileObsolete(…)等，是否会引起后续一些非预期的行为。
这种处理是否是bug，HasBGError()应该带锁进行判断？