aboutsummaryrefslogtreecommitdiffstats
path: root/activesupport/lib/active_support/concurrency
Commit message (Collapse)AuthorAgeFilesLines
* Share lock: more accurate livelock fix for aa598f4Jeremy Daer2016-04-241-3/+2
| | | | | | | | Awaken waiting threads even if the current thread (the previously exclusive thread) hadn't taken a share lock. This only happens in code that wasn't run within an executor, since that always take an outermost share lock.
* Share lock: avoid livelock due to exclusive thread sleeping before waiting ↵Jeremy Daer2016-04-231-0/+1
| | | | threads wake
* Manual yield doesn't block new sharesMatthew Draper2016-02-081-5/+6
|
* Eagerly reacquire when start_sharing is nested inside yield_sharesMatthew Draper2016-02-081-11/+18
| | | | A full write-preferring wait can lead to deadlock.
* Hand off the interlock to the new thread in AC::LiveMatthew Draper2016-02-071-15/+33
| | | | | | 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.
* After completing a load, give other threads a chance tooMatthew Draper2016-02-021-12/+26
| | | | | | | | | 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.
* While new sharers are blocked, an existing sharer remains re-entrantMatthew Draper2016-02-021-1/+1
|
* Block new share attempts if there's an exclusive waiterMatthew Draper2016-02-021-8/+12
|
* Require only necessary concurrent-ruby classes.Jerry D'Antonio2015-11-041-2/+2
|
* Handle thread death during lock acquisitionMatthew Draper2015-07-211-4/+6
| | | | | | 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.
* Adjust expectations around purpose/compatibility optionsMatthew Draper2015-07-211-1/+1
|
* Order of execution is only guaranteed if upgradingMatthew Draper2015-07-211-1/+1
| | | | | 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.
* Fix ShareLock issues.thedarkone2015-07-201-2/+2
|
* We need stricter locking before we can unloadMatthew Draper2015-07-201-27/+29
| | | | | | | | | | | | 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.
* Replaced `ActiveSupport::Concurrency::Latch` with concurrent-ruby.Jerry D'Antonio2015-07-131-16/+8
| | | | | | | | | | The concurrent-ruby gem is a toolset containing many concurrency utilities. Many of these utilities include runtime-specific optimizations when possible. Rather than clutter the Rails codebase with concurrency utilities separate from the core task, such tools can be superseded by similar tools in the more specialized gem. This commit replaces `ActiveSupport::Concurrency::Latch` with `Concurrent::CountDownLatch`, which is functionally equivalent.
* Document ShareLock and the InterlockMatthew Draper2015-07-091-0/+20
|
* Soften the lock requirements when eager_load is disabledMatthew Draper2015-07-091-0/+118
| | | | | We don't need to fully disable concurrent requests: just ensure that loads are performed in isolation.
* added live responses which can be written and read in separate threadsAaron Patterson2012-07-291-0/+27
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 18:48:20 +0000