aboutsummaryrefslogtreecommitdiffstats
path: root/activesupport/lib/active_support/concurrency/share_lock.rb
Commit message (Collapse)AuthorAgeFilesLines
* [Active Support] `rubocop -a --only Layout/EmptyLineAfterMagicComment`Koichi ITO2017-07-111-0/+1
|
* Use frozen-string-literal in ActiveSupportKir Shatrov2017-07-091-0/+1
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Fix broken comments indentation caused by rubocop auto-correct [ci skip]Ryuta Kamizono2016-09-141-1/+1
| | | | | | All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772. But comments was still kept absolute position. This commit aligns comments with method definitions for consistency.
* Add `Style/EmptyLines` in `.rubocop.yml` and remove extra empty linesRyuta Kamizono2016-08-071-1/+0
|
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-17/+17
|
* applies new string literal convention in activesupport/libXavier Noria2016-08-061-2/+2
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Provide a middleware to debug misbehaving locksMatthew Draper2016-06-101-5/+45
| | | | | Only intended to be enabled when in use; by necessity, it sits above any reasonable access control.
* 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
|
* 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.
* 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.