Just Software Solutions
justsoftwaresolutions.co.uk · Company blog · on HN since 2009
Anthony Williams, a C++ consultant, writes about C++ multithreading, atomics, synchronization, templates and standard library details.
What HN saysHN commenters link it as a reference for C++ threading and for the proposal to standardize variant in C++17.
18HN people shared it
3linked it in comments
22stories submitted
276story points
4 years agolast shared
2009people per year2026
Most-shared posts
- 1Multithreading in C++0x part 1: Starting Threads3 people · 7 points · first shared 2009 · 1 comments on HN
- 2Invariants and Preconditions2 people · 4 points · first shared 2020 · discussion on HN
- 3Locks, Mutexes, and Semaphores: Types of Synchronization Objects (2014)1 people · 96 points · first shared 2020 · 10 comments on HN
- 4Std::shared_ptr's secret constructor1 people · 87 points · first shared 2015 · 10 comments on HN
- 5Reclaiming C++ Data Structures with Cycles1 people · 55 points · first shared 2016 · 92 comments on HN
- 6Core C++ – lvalues and rvalues1 people · 4 points · first shared 2016 · discussion on HN
- 7Getting tuple elements with a runtime index in C++1 people · 3 points · first shared 2020 · discussion on HN
- 8Duplication in Software1 people · 2 points · first shared 2013 · discussion on HN
- 9C++0x Final Committee Draft Published1 people · 2 points · first shared 2010 · 1 comments on HN
- 10Using atomics for thread synchronization in C++1 people · 2 points · first shared 2021 · discussion on HN
- 11Delay Using a Database1 people · 2 points · first shared 2009 · 4 comments on HN
- 12Simplify Parallel Code by Encapsulating Locks1 people · 2 points · first shared 2011 · 1 comments on HN
- 13Object_ptr: Safer Replacement for Raw Pointers1 people · 2 points · first shared 2019 · discussion on HN
- 14Core C++ – Destructors and RAII1 people · 2 points · first shared 2015 · discussion on HN
- 15New Concurrency Features in C++141 people · 2 points · first shared 2015 · discussion on HN
What HN people wrote when they linked it
ramchip · 2017-09-02
If you're using a GUI toolkit like Qt or WxWidgets, then you have to use whatever event system the toolkit provides, since it controls the main thread's event loop. For WxWidgets for instance the doc is here: http://docs.wxwidgets.org/trunk/overview_thread.html
I worked on a C++ trading app in the past and our approach was "services" (actors) talking via message passing. Basically a bunch of long-lived threads, each with a queue (nowadays that could be something like boost::lockfree::queue [1]), running an event loop. Message passing worked by getting a pointer to the target service's queue via a service registry (singleton initialized at startup, you could also keep a copy per service though), then pushing a message to it. If you needed to do something with the result, then that would come back via another message sent via the same system.
It does mean if there's back-and-forth between services the code would be harder to follow as you'd have to read through a few event handlers to get the whole flow, but with well-designed service boundaries it worked quite well. I don't think futures would have been useful in our context as blocking any service for an extended time would have been very bad.
[1] If you don't want boost, you can wrap std::queue yourself, this is a simple example where you can replace the boost mutex etc. with std ones: https://www.justsoftwaresolutions.co.uk/threading/implementing-a-threa…
RotsiserMho · 2015-09-18
There's a proposal to include it in C++17. See also: https://www.justsoftwaresolutions.co.uk/cplusplus/standardizing-varian…
ysapir · 2013-05-11
Also, in this paradigm, only one thread calls refresh() at any give time (either the MonitorThread or before the thread is created, the initializer thread). This is contrary to some definitions of lock free, such as [1], "if any thread performing an operation on the data structure is suspended at any point during that operation then the other threads accessing the data structure must still be able to complete their tasks". If we kill MonitorThread, other threads accessing RSState won't be able to complete their operation.
[1] http://www.justsoftwaresolutions.co.uk/threading/non_blocking_lock_fre…