diff options
author | Todd Gamblin <tgamblin@llnl.gov> | 2019-12-21 16:31:28 -0800 |
---|---|---|
committer | Todd Gamblin <tgamblin@llnl.gov> | 2019-12-23 23:18:45 -0800 |
commit | d87ededddce53a8e3ae18ba8f75e206f6e395793 (patch) | |
tree | 808cd82ba8aaa9ddfc7ede39acd380993e87c710 /README.md | |
parent | b3a5f2e3c3ce4e3e9836301504f5b5987117248e (diff) | |
download | spack-d87ededddce53a8e3ae18ba8f75e206f6e395793.tar.gz spack-d87ededddce53a8e3ae18ba8f75e206f6e395793.tar.bz2 spack-d87ededddce53a8e3ae18ba8f75e206f6e395793.tar.xz spack-d87ededddce53a8e3ae18ba8f75e206f6e395793.zip |
lock transactions: avoid redundant reading in write transactions
Our `LockTransaction` class was reading overly aggressively. In cases
like this:
```
1 with spack.store.db.read_transaction():
2 with spack.store.db.write_transaction():
3 ...
```
The `ReadTransaction` on line 1 would read in the DB, but the
WriteTransaction on line 2 would read in the DB *again*, even though we
had a read lock the whole time. `WriteTransaction`s were only
considering nested writes to decide when to read, but they didn't know
when we already had a read lock.
- [x] `Lock.acquire_write()` return `False` in cases where we already had
a read lock.
Diffstat (limited to 'README.md')
0 files changed, 0 insertions, 0 deletions