AsynchronousLoader.GetObjectImmediately is used from many threads, all at once, when loading XML serializers during definition deserialization (via Storage.TryGetValue, via MyXmlSerializerManager)

The intended threading here is:

1. tA acquires the tracker lock
2. tB blocks on the tracker lock
3. tA reads the current job state, marks it as Working = true
4. tA releases the tracker lock
5. tA acquires the job target lock, and starts to load the item
6. tB with the tracker lock: reads the current job state, notes that it is already working
7. tB, blocks on the job target lock
8. tA finishes loading, releases the job target lock
9. tB with the job target lock, reads the value

The implementation of this has the potential to race where tA, the that that took ownership over loading the item, didn't acquire the work lock prior to tB, the thread that didn't take ownership over loading:

1. tA acquires the tracker lock
2. tB blocks on the tracker lock
3. tA reads the current job state, marks it as Working = true
4. tA releases the tracker lock
5. tB with the tracker lock: reads the current job state, notes that it is already working
6. tB, assuming that tA has already started work, acquires the job target lock
7. tB, immediately releases the job target lock, and assumes the job is done
8. tA acquires the job target lock and loads the item