3 ms·

>This is fairly low-level thread control, but in this article I won't detour into higher-level constructs like task-based parallelism, leaving this to some futu

>This is fairly low-level thread control, but in this article I won't detour into higher-level constructs like task-based parallelism, leaving this to some future post. That's fine, but just as an FYI to others: C++11 also provides some great tools for creating futures and promises that significantly simplify the work in multithreaded programming. In fact it closely resembles the conveniences I came to enjoy working in Clojure, which is considered to have a great approach to threading.

superfunc 11y ago
Also, if people should look at intel's tbb(https://www.threadingbuildingblocks.org/intel-tbb-tutorial https://www.threadingbuildingblocks.org/intel-tbb-tutorial) library, it has been really excellent in my experience using at a respectably large scale. edit: formatting
- bonzini 11y ago
  TBB is a little underwhelming in my opinion. Stuff like mutexes, condition variables and even atomics is pretty much standard nowadays (even if you need portability, you can usually rely on stuff like glib or Qt or boost); thread-safe collections are rarely the right solution, because too many fine-grained locks incur excessive overhead. The work-stealing queue is nice, but if you really want things to scale you need stuff like highly-parallel fast paths, with message passing on the slow paths. And this is where TBB falls a bit short of the expectations.
seivan 11y ago
I just wish GCD was ported everywhere and not just FreeBSD. It's much easier to work and think in terms of queues and groups than threads
pkolaczk 11y ago
I wonder what do you find so simplifying in futures and promises? I use them heavily in one of the projects and compared to old-school mutexes and condition variables they seem to be just at the same abstraction level. They can cause very similar problems like deadlocks or race conditions, with the additional "bonus" of callback hell if you don't use any higher-level libraries.

superfunc 11y ago

Also, if people should look at intel's tbb(https://www.threadingbuildingblocks.org/intel-tbb-tutorial https://www.threadingbuildingblocks.org/intel-tbb-tutorial) library, it has been really excellent in my experience using at a respectably large scale. edit: formatting

bonzini 11y ago
TBB is a little underwhelming in my opinion. Stuff like mutexes, condition variables and even atomics is pretty much standard nowadays (even if you need portability, you can usually rely on stuff like glib or Qt or boost); thread-safe collections are rarely the right solution, because too many fine-grained locks incur excessive overhead. The work-stealing queue is nice, but if you really want things to scale you need stuff like highly-parallel fast paths, with message passing on the slow paths. And this is where TBB falls a bit short of the expectations.

seivan 11y ago

I just wish GCD was ported everywhere and not just FreeBSD. It's much easier to work and think in terms of queues and groups than threads

pkolaczk 11y ago

I wonder what do you find so simplifying in futures and promises? I use them heavily in one of the projects and compared to old-school mutexes and condition variables they seem to be just at the same abstraction level. They can cause very similar problems like deadlocks or race conditions, with the additional "bonus" of callback hell if you don't use any higher-level libraries.