refactor(beatree): introduce a read transaction type #603
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
rphmeier
force-pushed
the
rh-basic-read-transaction
branch
from
ae57b58 to
1b81432
Compare
rphmeier
changed the base branch from
master
to
rh-THR-53-overflow-cell-value-hash
| // be invalidated by any destructive changes. | ||
| // | ||
| // Once this guard drops, it will be safe to initiate a new read transaction. | ||
| let read_tx_guard = read_transaction_latch.block_until_unique(); |
There was a problem hiding this comment.
I spent some time and I think I don't understand why this only blocks here but imediatelly released after we got the write. Why block then at all?
There was a problem hiding this comment.
It ensures that no new read transactions will be created until the write lock on self.shared is released in any case.
It would be fine to hold read_tx_guard until the end of this scope as well, of course. But not blocking would lead to a race, where we block_until_unique but then a new read transaction is created by another thread before we can acquire shared.write().
There was a problem hiding this comment.
Sure, but why is it important to exclude the new readers only for the duration of this scope?
rphmeier
force-pushed
the
rh-basic-read-transaction
branch
from
1b81432 to
1a981b5
Compare
pepyakin
changed the base branch from
rh-THR-53-overflow-cell-value-hash
to
graphite-base/603
pepyakin
force-pushed
the
rh-basic-read-transaction
branch
from
1a981b5 to
e08ba49
Compare
pepyakin
force-pushed
the
graphite-base/603
branch
from
ed25760 to
f96da7c
Compare
pepyakin
force-pushed
the
rh-basic-read-transaction
branch
from
e08ba49 to
6c5cbac
Compare
| *self.inner.read_transactions.lock() += 1; | ||
| } | ||
|
|
||
| fn block_until_unique(&self) -> MutexGuard<usize> { |
There was a problem hiding this comment.
this blocks until X gets unique.
What is X here?
| // be invalidated by any destructive changes. | ||
| // | ||
| // Once this guard drops, it will be safe to initiate a new read transaction. | ||
| let read_tx_guard = read_transaction_latch.block_until_unique(); |
There was a problem hiding this comment.
Sure, but why is it important to exclude the new readers only for the duration of this scope?
This introduces a basic read transaction type (not currently used) that is a first step towards enabling a safe asynchronous API for beatree. The immediate motivations are:
A less immediate but also useful goal is read transactions being used in
Sessions to enable parallel VMs to operate with fewer threads. This is groundwork for that future.Read transactions don't block commit or
finish_sync(leaving room for "async sync" in the future), but do blocksyncfrom beginning. We can expect that sync will start at a natural moment where there are no outstanding read transactions (after a session is committed). When a sync will end is less predictable, and leaving some space for pipelining will be beneficial.