servers: fix possible deadlock

[BurtonQin]

• Description:
  This PR fixes a possible deadlock bug in stratumserver.
  There are two Read locks on self.current_state in build_block_template() at L347 and L348.
  The first Read lock is not released before calling the second lock.
  The lock self.current_state is a parking_lot::RwLock.
  According to the doc of parking_lot::RwLock:
  “readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock.”
  “attempts to recursively acquire a read lock within a single thread may result in a deadlock.”
  Therefore, a deadlock may happen when a write lock interleaves the two read locks.

• How I fix:
  Use one read lock instead of two.

• Other Concerns:
  I notice that bh is also computed from self.current_state.
  Suppose that thread-A computes bh,
  thread-B changes self.current_state,
  then thread-A computes job_template. Is this interleaving okay?

[quentinlesceller]

Thank you for the PR @BurtonQin ! This look good to me 👍.

[hashmap]

While this change is fine I'm not sure about a deadlock here. Perhaps I'm missing smth, could you clarify it for me?

The first Read lock is not released before calling the second lock.

In this case we would get 100% deadlock, the same thread can't acquire the same lock twice (unlike in Java for example, where lock is reentrant), lock guard is dropped after evaluating an expression.

You are right, write lock could happen, but in this case we will wait for our turn to get a read lock, I don't see how it may cause a deadlock.

[hashmap]

Reg your last concern I share it, I'd prefer to get a read lock in the beginning to deal with a snapshot of the current_state.

[BurtonQin]

Because write() is prior to read().
Thread-A: Call read() and get the first lock.
Thread-B: Call write() and wait for read lock to release.
Thread-A: Call read() but cannot get the second lock because Thread-B is requesting write lock. Stuck here.

[hashmap]

Sorry, I still don't get why

Thread-B: Call write() and wait for read lock to release.

Thread-A will release (the first) read lock almost immediately, so write will block the second read for a while, but no big deal.

[BurtonQin]

The temporary lockguard returned by the first read() will live until the end of the statement, which covers the second read().

[hashmap]

Ah, it's a struct init, I missed it, you are right. I thought there are 2 different statements.