lock-free | 易学教程

SPSC lock free queue without atomics

阅读更多关于 SPSC lock free queue without atomics

问题 I have below a SPSC queue for my logger. It is certainly not a general-use SPSC lock-free queue. However, given a bunch of assumptions around how it will be used, target architecture etc, and a number of acceptable tradeoffs, which I go into detail below, my questions is basically, is it safe / does it work? It will only be used on x86_64 architecture, so writes to uint16_t will be atomic. Only the producer updates the tail . Only the consumer updates the head . If the producer reads an old

Is there a lock-free vector implementation?

阅读更多关于 Is there a lock-free vector implementation?

问题 First result in Google for "lock free vector" is a research paper cowritten by Damian Dechev, Peter Pirkelbauer and Bjarne Stroustrup describing a theoretical lock-free vector. Has this, or any other lock-free vector, been implemented? 回答1: MS provides ppl::concurrent_vector and Intel provides tbb::concurrent_vector. On Windows at least ppl and tbb are part of the C-Runtime. 回答2: I've just looked up what a vector is, in the wikipedia. I think (only a minute or two of thinking, mind) a fully

Why is lockless concurrency such a big deal (in Clojure)?

阅读更多关于 Why is lockless concurrency such a big deal (in Clojure)?

问题 I'm told that Clojure has lockless concurrency and that this is Important. I've used a number of languages but didn't realize they were performing locks behind the scenes. Why is this an advantage in Clojure (or in any language that has this feature)? 回答1: I can't speak about Clojure specifically, but ... it means you don't need to wait for someone to be done with something before you can get to work. Which is great. Typically it's achieved with immutable types. If nothing can be modified,

lock-free skiplist with rank operation

阅读更多关于 lock-free skiplist with rank operation

问题 Is anyone aware of any lock-free skiplist implimentations and/or research papers that support the rank operation (i.e. find kth element)? Alternatively, is anyone aware of a fundamental reason why such an operation could never work? Bonus points: An implimentation that does not assume garbage collection. It has been my experience quite a few research papers ignore memory management. Support: For a description of how the rank operation may be done in a regular skiplist: "A Skip List Cookbook"

How to correctly implement triple buffering?

阅读更多关于 How to correctly implement triple buffering?

问题 I am trying to simulate videocard (producer thread) and a monitor(consumer thread), to figure out what is going on in educational purposes. So here is the technical task description: Producer thread produces frames pixel data at 1000 fps. Consumer thread runs at 60 fps and every frame it must have access to last produced frame for at least 1/60th of second. Each frame is represented by some int* , for simplicity. So my solution is that i have array of 2 pointers: one for producer, one for

Tools to experiment with weakly ordered concurrency

阅读更多关于 Tools to experiment with weakly ordered concurrency

问题 What tools exist to help one to experiment with weakly ordered concurrency? That is, in what sandbox can one play while teaching oneself about partial fences, weak atomics, acquire/consume/release semantics, lock-free algorithms and the like? The tool or sandbox one wants would exercise and stress one's weakly ordered, threaded algorithm, exposing the various ways in which the algorithm might theoretically fail. Physically running on an x86, for example, the tool would nevertheless be able to

std::atomic treat a pair of atomic int32 as one atomic int64?

阅读更多关于 std::atomic treat a pair of atomic int32 as one atomic int64?

问题 I have a pair of unsigned int32 std::atomic<u32> _start; std::atomic<u32> _end; Sometimes I want to set start or end with compare exchange, so I don't want spurious failures that could be caused by using CAS on the entire 64bit pair. I just want to use 32 bit CAS. _end.compare_exchange_strong(old_end, new_end); Now I could fetch both start and end as one atomic 64bit read. Or two separate 32 bit reads. Wouldn't it be faster to do one 64bit atomic fetch (with the compiler adding the

Tools to experiment with weakly ordered concurrency

阅读更多关于 Tools to experiment with weakly ordered concurrency

What tools exist to help one to experiment with weakly ordered concurrency? That is, in what sandbox can one play while teaching oneself about partial fences, weak atomics, acquire/consume/release semantics, lock-free algorithms and the like? The tool or sandbox one wants would exercise and stress one's weakly ordered, threaded algorithm, exposing the various ways in which the algorithm might theoretically fail. Physically running on an x86, for example, the tool would nevertheless be able to expose ARM-type failures. An open-source tool would be preferable. Please advise. References: the C+

Dynamic generation & safe usage of spsc_queues

阅读更多关于 Dynamic generation & safe usage of spsc_queues

问题 The only boost::lockfree that I've made work is spsc_queue , and it's amazing. However, I'd like to implement it where one thread passes information back and forth with cores - 1 threads. I was thinking that each of the worker threads would have its own set of spsc_queues , in and out, which would be stored in vector s where the main thread would pass information to one outgoing queue and then move to the next queue in the vector and so on as well as cycle through the incoming queues. Can

Lock-free cache implementation in C++11

阅读更多关于 Lock-free cache implementation in C++11

Is there any way in C++11 to implement a lock-free cache for an object, which would be safe to access from multiple threads? The calculation I'm looking to cache isn't super cheap but also isn't super expensive, so requiring a lock would defeat the purpose of caching in my case. IIUC, std::atomic isn't guaranteed to be lock-free. Edit: Since calculate isn't -too- expensive, I actually don't mind if it runs once or twice too many. But I -do- need to make sure all consumers get the correct value. In the naive example below, this isn't guaranteed because due to memory re-ordering it's possible