lockfree | Lockfree data structures for Rust | Map library

Apparently I've been doing it wrong this whole time. You shouldn't set --prefix and --stagedir to the same location. Previous iterations of boost don't seem to care about this issue. One of the later versions started caring which caused my problem.

You're leaking worker because you used new to construct it and never use delete to destruct it. The other ASan messages are there because as part of constructing worker, its member queue is also constructed.

The C++ standard doesn't concern itself with multiple processes, so there can't be any formal answers. This answer will assume the program behaves more or less the same with processes as with threads in regards to synchronization.

The first solution requires C++20 atomic_ref

It turns out that it is possible to build all of Boost while using ICU for those components that support the ICU feature, as follows.

./vcpkg install boost-locale[icu] boost-regex[icu] boost --triplet x64-windows --recurse

Source: How do I build boost with ICU support without having to build most components of boost twice?

First, let's fix the bigger performance problem first. Your main Win32 thread is spinning without waiting. That's going to negate any perceived performance difference between a lockless bool and an std::atomic.

You'll burn an entire core just invoking PeekMessage redundantly on an empty queue. So instead of this:

spsc_queue doesn't have operator()(int) in its interface. Now your compiler complains to queue(capacity); - this calls opearator()(int) on queue instance.

I assume your intention is to call ctor of spsc_queue with capacity as argument.

So add helper method to calculate this capacity and pass it to queue constructor on initialization list:

Your Event class has a member of type std::string, which has a non-trivial assignment operator and a non-trivial destructor. Those stop the auto-generated assignment operator and destructor of Event itself from being trivial. (Remember, "trivial" doesn't just mean "defaulted". It also means that the default behavior doesn't have to do anything interesting. A trivial assignment is just copying bits; a trivial destructor is a no-op.)

It appears Boost's LF multi-producer multi-consumer queue implementation doesn't support this. Other MPMC queues might.

boost::lockfree::spsc_queue (single-producer single-consumer ring-buffer queue) does, with spsc.write_available() > 0.

boost::lockfree::queue is not fixed-size by default, only if you pass a capacity as a template arg, or fixed_sized. If the data structure is configured as fixed-sized, the internal nodes are stored inside an array and they are addressed by array indexing. (But it's not a ring-buffer like some other MPMC queues.) Otherwise they're dynamically allocated and kept on a free-list.

For performance you probably should make it fixed-size. Or if you want to limit dynamic allocation, you can use bounded_push instead of push, so it will return false instead of going to the OS for more memory (which might not be lock-free).

If you are using a queue>, then it is possible for the queue to become full.

But It wouldn't be very meaningful to check separately because another producer could have made the queue full between the check and the push. Are you looking for a performance optimization like avoiding constructing the object if the queue would probably still be full by the time you're ready to call push?

(Also, a consumer could make the queue non-full right after you check, so it really only makes sense to check as part of an attempted push. And perhaps there isn't even an efficient lock-free way to check. Otherwise they could have had the function always return true for non-fixed-size queues, and return a meaningful result for fixed-size.)

This is why push() returns bool: false means the queue was full (or a new node couldn't be allocated for non-fixed-size queues).

Before Popping the queue I can check the queue for empty status by Foo.empty() function.

I hope you're not actually doing this; it has all the same problems of racing with other threads as push, and with fewer opportunities to optimize. There's no object to construct before the attempt, you just call pop and see if you get one or not.

Another thread could have made the queue empty, or made it non-empty, between your check and your actual pop. Unless you're the only consumer, in which case seeing non-empty does mean you can definitely pop. A multi-producer single-consumer use-case would not be compatible with spsc_queue.

Anyway, this is why it's bool pop(T &); not T pop().

Why the name lockFREE? is it suggesting cannot be (mutex) locked?

Of course anything can be locked; you put the mutex outside the data structure and have every thread that touches the data structure use it.

boost::lockfree::queue provides unsynchronized_pop and unsynchronized_push for use in cases where you've ensured that only one thread can be accessing the queue.

But the main purpose of lockfree::queue and of lockless algorithms / data structures is that they don't need to be locked: multiple threads can safely write and/or read at the same time.

"lock free" has 2 meanings in programming, leading to potentially confusing but true statements like "this lockless algorithm is not lock-free".

• Casual usage: synonym for lockless - implemented without mutexes, using atomic loads, stores, and RMW operations like CAS or std::atomic::atomic_fetch_add. See for example An Introduction to Lock-Free Programming (Jeff Preshing). And maybe What every systems programmer should know about concurrency.

  std::shared_ptr uses lockless atomic operations to manage its control block. C++11 std::atomic<> provides lockless primitives for custom algorithms. See stdatomic. Normally in C++11, unsynchronized access to the same variable by multiple threads is undefined behaviour. (Unless they're all read-only.) But std::atomic gives you well-defined behaviour, with your choice of sequential-consistency, acquire/release, or relaxed memory ordering.

• Technical computer-science meaning: a thread sleeping forever or being killed won't block the rest of the threads. i.e. guaranteed forward progress for the program as a whole (at least one thread). (Wait-free is when threads never have to retry). See https://en.wikipedia.org/wiki/Non-blocking_algorithm. A CAS retry loop is a classic example of lock-free but not wait-free. Wait-free is stuff like RCU (read-copy-update) read threads, or depending on definitions, a atomic_fetch_add on hardware that implements it as a primitive (e.g. x86 xadd), not in terms of an LL/SC or CAS retry loop.

Most lockless multi-reader / multi-writer queues are not lock-free in the technical sense. Usually they use a circular buffer, and a writer will "claim" an entry somehow (fixing its order in the queue). but it can't be read until the writer finishes writing to the entry itself.

See Lock-free Progress Guarantees for an example with analysis of its possible blocking behaviour. A writer atomically increments a write-index, then writes data into the array entry. If the writer sleeps between doing those things, other writers can fill up the later entries while readers are stuck waiting for that claimed but not written entry. (I haven't looked at boost::lockfree::queue, but presumably it's similar¹.)

In practice performance is excellent with very low contention between writers and readers. But in theory a writer could block at just the wrong moment and stall the whole queue.

Footnote 1: The other plausible option for a queue is a a linked list. In that case you can fully construct a new node and then attempt to CAS it into the list. So if you succeed at adding it, then other threads can read it right away because you have its pointers set correctly.

But the reclaim problem (safely freeing memory that other threads might be reading to see if another reader has already claimed them) is extremely thorny outside of garbage-collected languages / environments. (e.g. Java)

boost::lockfree::queue queue(128); Why 128?

That's the queue (max) size, in entries. Of int in this case, because you used queue, duh. As mentioned above, most lockless queues use a fixed size circular buffer. It can't realloc and copy like std::vector when it needs to grow, because other threads can be reading it simultaneously.

As documented in the manual (the first google hit for boost::lockfree::queue), the explicit queue(size_type) constructor takes a size.

You could also bake the capacity into the type, by using it as a template parameter. (So the capacity becomes a compile-time constant everywhere that uses the queue, not just in places that can do constant-propagation from the constructor call.)

The class apparently doesn't enforce / require a power-of-2 size, so a template size parameter could maybe optimize significantly better by letting % capacity operations compile into an AND with a mask instead of a division.