Hell is a multi-threaded C++ program (2006)

Post by shaklee3 » Sat, Sep 02, 2017, 11:15 PM UTC

ridiculous_fish wrote: post #33

andreasgonewild wrote: post #8

There is no need to use raw pthreads in modern C++, it comes equipped with a much more convenient and capable standard library module. I prefer working with channels, which are still missing from the library; but they are trivial to add: https://github.com/andreas-gone-wild/blog/blob/master/diy_cp...

Unfortunately std::thread is not as capable as pthreads. For example, std::thread has no facilities for controlling the stack size or signal mask. Whenever I use channels, I find I need them to synchronize with each other. For example, I have a Go data structure with a write channel and a separate read channel; how do I avoid a read-after-write hazard? The simplest solution is to make them the same channel that ships…

Post by to3m » Sat, Sep 02, 2017, 11:23 PM UTC

ridiculous_fish wrote: post #33

andreasgonewild wrote: post #8

There is no need to use raw pthreads in modern C++, it comes equipped with a much more convenient and capable standard library module. I prefer working with channels, which are still missing from the library; but they are trivial to add: https://github.com/andreas-gone-wild/blog/blob/master/diy_cp...

Unfortunately std::thread is not as capable as pthreads. For example, std::thread has no facilities for controlling the stack size or signal mask. Whenever I use channels, I find I need them to synchronize with each other. For example, I have a Go data structure with a write channel and a separate read channel; how do I avoid a read-after-write hazard? The simplest solution is to make them the same channel that ships…

Post by to3m » Sat, Sep 02, 2017, 11:24 PM UTC

shaklee3 wrote: post #41

ridiculous_fish wrote: post #33

Earlier quoted context omitted.

Unfortunately std::thread is not as capable as pthreads. For example, std::thread has no facilities for controlling the stack size or signal mask. Whenever I use channels, I find I need them to synchronize with each other. For example, I have a Go data structure with a write channel and a separate read channel; how do I avoid a read-after-write hazard? The simplest solution is to make them the same channel that ships…

You can get the underlying pthread pointer if you want.

Post by danieltillett » Sat, Sep 02, 2017, 11:32 PM UTC

fnj wrote: post #39

noobermin wrote: post #9

So to check, I googled C++11 threads memory model, and it[0] looks like his main complaint isn't helped by C++ 11 threads, as they essentially allow shared state too. They are also a thin veneer over the OS threads, for unix types, pthreads I imagine. [0] http://en.cppreference.com/w/cpp/language/memory_model

Honest question: If you aren't going to share data between/among threads, why use threads at all? Why not just fork-abd-exec?

Post by mianos » Sat, Sep 02, 2017, 11:44 PM UTC

oppositelock wrote: post #17

I've been writing massively threaded C++ code since the 1990's, so I can comment with some serious experience here. My code used to run on 256CPU SGI's and had high cpu utilization across all of them. When designing C++ code for threading, you have to keep a few things in mind, but it's not particularly harder than on other languages with thread support. You generally want to create re-entrant functions which pass al…