about summary refs log tree commit diff
path: root/src/libstd/rt/deque.rs
AgeCommit message (Collapse)AuthorLines
2013-12-24std: Introduce std::syncAlex Crichton-658/+0
For now, this moves the following modules to std::sync * UnsafeArc (also removed unwrap method) * mpsc_queue * spsc_queue * atomics * mpmc_bounded_queue * deque We may want to remove some of the queues, but for now this moves things out of std::rt into std::sync
2013-12-15librustc: Remove identifiers named `box`, since it's about to become a keyword.Patrick Walton-3/+3
2013-12-10libstd: Remove two uses of `Cell`.Patrick Walton-3/+2
2013-12-04Rename std::rt::deque::*::init() to *::new()Kevin Ballard-14/+14
2013-11-29Ignore a deque test on windowsAlex Crichton-0/+1
I've seen this fail on windows twice now, and it's not clear to me why it's failing. For now, ignore it on that platform while investigation enuses.
2013-11-29Implement a lock-free work-stealing dequeAlex Crichton-0/+658
This adds an implementation of the Chase-Lev work-stealing deque to libstd under std::rt::deque. I've been unable to break the implementation of the deque itself, and it's not super highly optimized just yet (everything uses a SeqCst memory ordering). The major snag in implementing the chase-lev deque is that the buffers used to store data internally cannot get deallocated back to the OS. In the meantime, a shared buffer pool (synchronized by a normal mutex) is used to deallocate/allocate buffers from. This is done in hope of not overcommitting too much memory. It is in theory possible to eventually free the buffers, but one must be very careful in doing so. I was unable to get some good numbers from src/test/bench tests (I don't think many of them are slamming the work queue that much), but I was able to get some good numbers from one of my own tests. In a recent rewrite of select::select(), I found that my implementation was incredibly slow due to contention on the shared work queue. Upon switching to the parallel deque, I saw the contention drop to 0 and the runtime go from 1.6s to 0.9s with the most amount of time spent in libuv awakening the schedulers (plus allocations). Closes #4877