the multithread thread

category: code [glöplog]
Read up on C++11s threading feature: std::thread, std::async and futures and promises. Nice shit, now we only need compilers that support it...

added on the 2012-02-06 11:31:26 by raer raer
use Qt and never look back.
added on the 2012-02-06 12:12:51 by Navis Navis
Even better: Use Qt AND C++11... ;)
With C++11 you won't need extra DLLS. But I agree, Qt is pretty awesome, established AND multi-platform.
added on the 2012-02-06 12:36:57 by raer raer
use .NET with async CTP and never look back.
added on the 2012-02-07 08:42:48 by skrebbel skrebbel
Personally, I found that the combination of multithreading and the average programming skills often leads to impossible-to-find architectural bugs.

Unless it's really needed, I would go a long way to keep things simple and one threaded.
added on the 2012-02-07 08:51:47 by TLM TLM
added on the 2012-02-07 09:13:51 by spike spike
.NET still has a garbage collector that suspends _all_ threads while doing its work. Therefore it does not scale very well to multiple threads. Therfore its useless for HPC. The only way to curcumvent this is to create multiple CLR's.
added on the 2012-02-07 09:16:50 by ddeml ddeml
btw. anyone knows where to find the spinlock code by Intel that chaos mentions in his seminar? So far my google skills were not able to dig it up..
added on the 2012-02-07 13:35:24 by spike spike
@ddeml: Check the Automatic Memory Management (Garbage Collection) section. The default workstation GC only does so if it has to. Normally not since it would halt any UI. The server version does it because it creates the highest performance but you can use the workstation GC if you want to.
added on the 2012-02-07 18:28:52 by Xetick Xetick
Something to consider is also to make memory efficient processes: If you multithread stupidly in a way that trashes the caches all over the place, you may end up with something slower than an actual single threaded implementation.
added on the 2012-02-07 22:00:36 by Dbug Dbug
Code::() { : | :& }; :
added on the 2012-02-07 23:11:50 by Joghurt Joghurt
@xetick i cannot load the link ("Http/1.1 Service Unavailable"). However I am aware of the two GC flavours. In my use case, it didnt make any difference. There are as many worker threads as hardware threads running at 100%. So the GC will never find time to work in background. And i consider this a normal use case in a HPC task. Also, i found no way to prevent new allocations as sometimes they happen in system code or even in compiler generated code (boxing). So eventually the GC _will_ suspend all threads if it does so by design.
I would prefer some possibility to maintain separate heaps so that each thread can have one heap and GCing this heap will only affect this thread. Or a GC that does not suspend all threads whein in action, but from what i know, this is not doable in an effective way.
added on the 2012-02-08 09:44:43 by ddeml ddeml
This thread has been temporarily suspended by the scheduler in order to give processing time to another thread about traveling.