| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
A full write-preferring wait can lead to deadlock.
|
| |
|
|
|
|
| |
Most importantly, the original request thread must yield its share lock
while waiting for the live thread to commit -- otherwise a request's
base and live threads can deadlock against each other.
|
| |
|
|
|
|
|
|
|
| |
While we know no user code is running, we should do as much loading as
we can. That way, all the threads will then be able to resume running
user code together.
Otherwise, only the last arriving thread would get to do its load, and
would then return to userspace, leaving the others still blocked.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Specifically, clean up if the thread is killed while it's blocked
awaiting the lock... if we get killed on some other arbitrary line, the
result remains quite undefined.
|
| | |
|
| |
|
|
|
| |
If the thread isn't yet holding any form of lock, it has no claim over
what may / may not run while it's blocked.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Specifically, the "loose upgrades" behaviour that allows us to obtain an
exclusive right to load things while other requests are in progress (but
waiting on the exclusive lock for themselves) prevents us from treating
load & unload interchangeably: new things appearing is fine, but they do
*not* expect previously-present constants to vanish.
We can still use loose upgrades for unloading -- once someone has
decided to unload, they don't really care if someone else gets there
first -- it just needs to be tracked separately.
|
| | |
|
|
|
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
