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...
use Qt and never look back.
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.
With C++11 you won't need extra DLLS. But I agree, Qt is pretty awesome, established AND multi-platform.
use .NET with async CTP and never look back.
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.
Unless it's really needed, I would go a long way to keep things simple and one threaded.
shameless plug: Implementing a Work-Stealing Scheduler
.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.
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..
@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.
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.
Code:
:() { : | :& }; :
@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.
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.
This thread has been temporarily suspended by the scheduler in order to give processing time to another thread about traveling.
