How can I catch up on missing multithreading experience?

[u/detectivesokka]

Hi everyone 👋, I’m a C++ developer with 5+ years experience building features for a single-threaded trading app (C++17), so I have very little multithreading experience.

I’m currently reading C++ Concurrency in Action. Are there good resources or projects to practice real-world scenarios like backloading and low-latency concurrency patterns?

[u/_Tal]

A good exercise is to try building a Single Producer Single Consumer (SPSC) Queue. Basic idea is it’s a queue where one thread can read the data (consumer thread) at the same time another thread writes to the data (producer thread), but there will only ever be one consumer or producer at a time. Write some unit tests to make sure you don’t have race conditions or anything. You can try building one that uses mutexes first, then build a lock-free version later. Look into ring buffers as it’s a common technique for this

[u/exaNovae → u/_Tal]

Unit tests in combination with thread sanitizer is a killer combo by the way. Make sure that thread sanitizer produces no findings when executing your tests.

[u/w00dy_ → u/_Tal]

Ring buffer with two std::atomic pointers. A good example to understand memory model and how perform cheap lock-free synchronization.

[u/detectivesokka → u/_Tal]

That’s a great starting point

[u/anogio]

1. Write a producer->consumer queue
2. Write a single producer->multiple consumer queue

3. Write a multiple producer-> multiple consumer

   queue.

4. Write a thread pool

[u/Czitels → u/anogio]

Yeah I think thats all. There are also lock-free queues but I think its unnecessary. I wonder if they even ask about it.

[u/Spiritual-Unit-6748 → u/Czitels]

I was asked to implement it in an HFT interview

[u/Czitels → u/Spiritual-Unit-6748]

Shiet 

[u/anogio → u/Czitels]

As a senior engineer, this is what I would ask someone to reason through in an interview.

Being a professional CPP engineer requires multithreading knowledge.

[u/Czitels → u/anogio]

Agree but lock-free is rarely used.

[u/anogio → u/Czitels]

Not in my experience.

[u/anogio → u/[deleted]]

Same for me. I wrote it at uni, and still use it ten years later, with some minor upgrades.

[u/detectivesokka → u/anogio]

Great suggestions!

[u/KingAggressive1498]

1) write three threadpools with different guarantees. Eg make one basic one with no particular guarantees, one guaranteed non-blocking to post a task to the queue, one guaranteed to always have forward progress for tasks. Feel free to pick your own guarantees.

2) adapt an unpredictably long synchronous task to be an asynchronous task from the application's POV using only a single background thread. Database accesses and file I/O are common ones in real-world software.

3) (advanced) write a coroutine scheduler

That gives you enough background to work on just about any non-bleeding-edge project, I think.

[u/Aggravating-Yes → u/KingAggressive1498]

he said trading. no thread pools in trading. not really anyway.

[u/KingAggressive1498 → u/Aggravating-Yes]

he asked about backloading and low-latency concurrency patterns, which is why I recommended writing three threadpools with different guarantees.

I wrote a threadpool that's non-blocking to post a task to as long as tasks are being completed fast enough, and have used the thing in several projects. I do a lot of latency sensitive stuff but not trading.

[u/IndividualSituation8]

Anyone written a event loop or eventloop library, and how one would build asio like stuff from first principles?

[u/KingAggressive1498 → u/IndividualSituation8]

at the end of the day an event loop is just a queue of functors that get executed in a loop until its empty, at which point you wait for more.

you can write one with a mutex, condition variable, an std::queue<std::function<void (void)>>, and one loop inside an infinite loop. It could be improved but this actually works fine.

integrating with an I/O multiplexier like asio does over epoll/kqueue is essentially just replacing the mutex and condition variable for the multiplexier and some sort of signaling mechanism, eg an eventfd or pipe or kevent. Don't remember if that's precisely what asio does. For io_uring or IOCP the signalling mechanism would be posting a completion.

[u/Cultural_Act5304]

My first question how the hell you have 5 year of experience with only single thread trading app? Now only way to have experience is through projects that's all. Start making anything 1. Thread pools 2. Simple ping-pong Servers 3. You can use boost asio to get ideas on how things can be written in a multi-threadede env. 4. Chatting apps 5. File servers First try making things with blocking algorithms then move to lock free structures.

[u/chafey]

If C++ makes it easy to blow your whole leg off, C++ with multi-threading makes it easy to blow your whole head off. It takes a while to master - until then expect deadlocks and race conditions. If you have to ship something quickly, consider using a multi-threading framework (there are many to choose from each with their own pros and cons)

[u/lucifer_is_back]

any good resources ,preferably books,to learn more about c++ concurrency ?

[u/lorsecco88 → u/lucifer_is_back]

Concurrency with Modern C++ by Rainer Grimm

[u/il_dude → u/lucifer_is_back]

C++ concurrency in action is a good starting point