summaryrefslogtreecommitdiff
path: root/var
diff options
context:
space:
mode:
authorTodd Gamblin <tgamblin@llnl.gov>2019-12-21 16:31:28 -0800
committerTodd Gamblin <tgamblin@llnl.gov>2019-12-23 18:36:56 -0800
commit6c9467e8c6d5fffa6d9412d5d36ff2c91e33ea21 (patch)
tree2a409312016669933ca7c3e9271a024ad024c050 /var
parentbb517fdb8433ddb18b286c185403c7e1bc7eaae5 (diff)
downloadspack-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 'var')
0 files changed, 0 insertions, 0 deletions