Hell is a multi-threaded C++ program (2006) • Hacker News Board

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

#81

Post by iainmerrick » Sun, Sep 03, 2017, 5:22 AM UTC

ibrault wrote: post #73

deepGem wrote: post #63

Earlier quoted context omitted.

I am not as experienced as you are and I don't even know the term re-entrant functions but accidentally this is how I am now designing programs, mostly writing self contained functions that don't alter any global state. This approach has made my programming life hell because I am finding it incredibly hard to get rid of the old shared variables habit. What I have experienced is that shared data access is more or less…

Re-entrant is basically what you said, self-contained functions that don't depend on external state. The "re-entrant" part just means that, basically, the function can be "re-entered." If it gets interrupted in the middle of execution, it will still produce the same output no matter what, no matter how long it sleeps for.

No, that's not what re-entrant means. A re-entrant function can be called multiple times at the same time.

That could be from different threads or from an interrupt handler. It can even come up in single-threaded code: you call function A() which internally calls B() which results in a nested call to A(). If A is re-entrant that's safe.

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

#82

Post by iainmerrick » Sun, Sep 03, 2017, 5:41 AM UTC

Pthreads seems to be getting a bad name here, but compared to other low-level threading APIs it's excellent. It has a proper join operation, which is weirdly lacking in some other libraries I've used, and it has a good choice of key synchronisation primitive: condition variables. Other choices are possible, like semaphores, but those are fiddly to use for some applications. Building semaphores on top of CVs is pretty easy, building CVs on top of semaphores is very hard. Likewise Windows events.

Higher-level systems have primitives like message queues, thread pools, and channels. Those are all great but they can't always be used to build the exact system you need without a lot of overhead.

C and C++ are all about emphasising speed and flexibility over safety. Whether you think that's a good or bad approach, it is what it is, and pthreads is the right design for that approach. Once you come up with the high-level multithreading abstraction of your dreams, what else would you rather implement it in than pthreads?

The one thing that was missing from pthreads was atomic operations for modern lockless data structures, so it's great that those have finally been added to the standard library in both C and C++.

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

#83

Post by syngrog66 » Sun, Sep 03, 2017, 5:43 AM 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…

this comment reeks of experience, expertise and pragmatism. thank you! -- programming for 30 years

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

#84

Post by iainmerrick » Sun, Sep 03, 2017, 5:45 AM UTC

asveikau wrote: post #53

clishem wrote: post #26

Earlier quoted context omitted.

> lack of thread local storage is not an issue We've had it since C++11. http://en.cppreference.com/w/cpp/language/storage_duration

I think android ndk still barfs on c++11 tls and the earlier language extensions that came before it like __thread. It's not uncommon to be working with language implementations that are missing things like that. (I remember MS's version of it produced binaries that would not run on XP - maybe less important today but I had a run-in with that circa 2009.)

Really? That's disappointing. Good old bad old NDK strikes again. I really don't understand why Google doesn't seem interested in fixing it.

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

#85

Post by syngrog66 » Sun, Sep 03, 2017, 5:46 AM UTC

WalterBright wrote: post #32

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…

The D programming language has a 'pure' annotation which can be applied to functions. This enables the compiler checking that the function does not read or write any global mutable state, including checking the functions called. After using it for a while, it's amazing how much global variables tend to creep unannounced into code :-)

great feature, sir. thank you!

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

#86

Post by WalterBright » Sun, Sep 03, 2017, 6:13 AM UTC

syngrog66 wrote: post #85

WalterBright wrote: post #32

Earlier quoted context omitted.

The D programming language has a 'pure' annotation which can be applied to functions. This enables the compiler checking that the function does not read or write any global mutable state, including checking the functions called. After using it for a while, it's amazing how much global variables tend to creep unannounced into code :-)

great feature, sir. thank you!

You're welcome! It's a 'little' feature with a surprisingly large impact.

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

#87

Post by syngrog66 » Sun, Sep 03, 2017, 6:30 AM UTC

rdtsc wrote: post #69

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…

Obviously it is possible to write threaded C++ programs. And there are experienced people like you who can do it well, with enough discipline, good design, and so on. But I think the point of the article is that for most programmers it is very easy to make mistakes and shoot themselves in the foot with threads and shared memory. It could be even something like using a 3rd party library where it's initialization conte…

thank you

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

#88

Post by pcwalton » Sun, Sep 03, 2017, 6:36 AM UTC

asveikau wrote: post #52

pcwalton wrote: post #48

Earlier quoted context omitted.

> True C++ hell is taking a single threaded C++ program and making it multi-threaded after the fact, but that's hell in any language which allows you to have globals of any sort and doesn't perform function calls within some kind of closure. That's not true. In Rust you can have globals, but you have to declare the synchronization semantics for every global when you do. (That is, they have to be read only, or thread…

> you have to declare the synchronization semantics for every global when you do. (That is, they have to be read only, or thread local, or atomic, or protected by a lock.) That doesn't sound like it helps you determine which one of those is appropriate. So it seems rather like a system that will lead to unexpected bottlenecks when you parallelize. (Somebody deep inside the stack arbitrarily decided locking was the mo…

This is usually not a problem because using globals and taking locks unnecessarily is unidiomatic Rust. You have to go out of your way to write more code when you use mutexes, so most people don't unless they truly need to.

We have experience with this. For a long time, WebRender rasterized glyphs and other resources sequentially. Switching it to parallelize was painless: Glenn just added a parallel for loop from Rayon and we got speedups.

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

#89

Post by [deleted] » Sun, Sep 03, 2017, 6:37 AM UTC

nemoniac wrote: post #21

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…

So, functional programming then?

[deleted]

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

#90

Post by cm2187 » Sun, Sep 03, 2017, 6:38 AM UTC

oppositelock wrote: post #22

nemoniac wrote: post #21

Earlier quoted context omitted.

So, functional programming then?

Yup, basically.

It's not exactly functional programming. It can be a traditional OOP, just structured in independent blocks, and you execute each block on different threads. But the block internally can have as much shared state as it wants.

You get the simplicity and familiarity of OOP and most of the benefits of multi-threading.