On Thu, Dec 26, 2013 at 2:10 PM, comex <com...@gmail.com> wrote: > On Wed, Dec 25, 2013 at 4:23 AM, Daniel Micay <danielmi...@gmail.com> wrote: >> It makes sense to allocate it up-front for some lock-free queues but >> not a classical one built on a mutex and two condition variables. I >> doubt that a lock-free algorithm with have any significant wins >> against a Linux mutex or Windows critical section, and on Haswell lock >> elision erases the theoretical benefits too. > > I'm skeptical of the claim that a lock-free algorithm would not have > any significant benefits. Do you have a citation?
Acquiring and releasing a mutex when there's low contention takes two atomic operations. Switching to a linked data structure adds far more overhead than an extra atomic operation. Intel Thread Building Blocks makes exclusive use of locking for both the non-blocking and blocking concurrent queues because it performs as well as lock-free implementations without losing priority-aware multiple-producer/multiple-consumer support. A simple array-backed circular buffer has a tiny lock scope, so it won't ever have high contention. In a less simple case, a mutex will spin for a bit before falling back to a `futex` system call. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
