|
Description:
|
If Run.onLoad takes a little while to run, or generally if RunMap.retrieve is not instantaneous, a race condition can arise. Say thread 1 calls getByNumber for a Run which in fact exists on disk (with a numeric symlink). search will call load(int, null), which will delegate to load(File, null) which acquires the lock; and then blocks for a while in retrieve. Then thread 2 calls getById with the ID of the same build. index.byId is still empty, so it jumps to load(String, null) and then blocks waiting to enter load(File, null). Now thread 1 finishes retrieve, stores the newly loaded Run in the index, and returns. When the lock is released, thread 2 enters it, loads another copy of the same Run, and stores it in the index, clobbering the first entry, and returns that.
Seems to be fixable by making getById double-check the index while holding the lock, forcing it to wait for the first thread to store an entry. (Or could just check under lock whether snapshot != index, and if so, retry.)
Also load(File, null) should assert that there is no current entry for a build before it stores one.
|
