summaryrefslogtreecommitdiff
path: root/.travis.yml
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 23:18:45 -0800
commitd87ededddce53a8e3ae18ba8f75e206f6e395793 (patch)
tree808cd82ba8aaa9ddfc7ede39acd380993e87c710 /.travis.yml
parentb3a5f2e3c3ce4e3e9836301504f5b5987117248e (diff)
downloadspack-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 '.travis.yml')
0 files changed, 0 insertions, 0 deletions