Safety around `NextWriteNoWriteConflictRange` logic in parallel context.
#206 ouverte le 27 sept. 2020
Métriques du dépôt
- Stars
- (157 stars)
- Métriques de merge PR
- (Métriques PR en attente)
Description
Currently set_option only require a reference to the transaction to work.
This means it can be called by multiple thread in parallel without ownership of the transaction.
There is currently one option that concerns me: NextWriteNoWriteConflictRange
The next write performed on this transaction will not generate a write conflict range. As a result, other transactions which read the key(s) being modified by the next write will not conflict with this transaction. Care needs to be taken when using this option on a transaction that is shared between multiple threads. When setting this option, write conflict ranges will be disabled on the next write operation, regardless of what thread it is on.
There are multiple ways to prevent that :
- give access to a new API with mutex protection (add complexity on Transaction struct
Option<Box<Mutex>>) - protect the affected method/option by requiring a mutable reference to the transaction, safe but might create a pain to use it
- only protect
NextWriteNoWriteConflictRangewith a global (😒) mutex (or something clever) - do nothing and let users handle that themselves