diff options
author | Todd Gamblin <tgamblin@llnl.gov> | 2019-12-21 16:31:28 -0800 |
---|---|---|
committer | Todd Gamblin <tgamblin@llnl.gov> | 2019-12-23 18:36:56 -0800 |
commit | 6c9467e8c6d5fffa6d9412d5d36ff2c91e33ea21 (patch) | |
tree | 2a409312016669933ca7c3e9271a024ad024c050 /bin/spack-python | |
parent | bb517fdb8433ddb18b286c185403c7e1bc7eaae5 (diff) | |
download | spack-6c9467e8c6d5fffa6d9412d5d36ff2c91e33ea21.tar.gz spack-6c9467e8c6d5fffa6d9412d5d36ff2c91e33ea21.tar.bz2 spack-6c9467e8c6d5fffa6d9412d5d36ff2c91e33ea21.tar.xz spack-6c9467e8c6d5fffa6d9412d5d36ff2c91e33ea21.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 'bin/spack-python')
0 files changed, 0 insertions, 0 deletions