Also, this might be a retarded idea but it added to my performance - measure each task (function that is needed to be passed to these worker threads which at me are 4*NR_CORES), and give "points" to that task. Then, when assigning it to a thread, assign it to the thread which has the minimal "points" (of course add, subtract). This can be used best if you can keep the tasks as close in time to each other as much as possible.
That's probably easier said than done ... a lot easier said than done
Its very easily done, concurrent collections and the Parallel features in C# mean that all the work is basically done for you, just use them when access collections which multiple threads will work on (if only 1 thread will work on a collection you don't need the concurrency). And use a lock object for things like loading files to ensure you don't load the same thing twice if multiple threads have the potential to do that at the same time.
Sorry guys, Jack is correct. I don't know why you all are whining about multithreading being so difficult. That's kind of the reason .NET had an entire update or two dedicated to safe multithreading and concurrency. Even before that though, multithreading wasn't challenging. All it required was a bit of Googling.
Its very easily done, concurrent collections and the Parallel features in C# mean that all the work is basically done for you, just use them when access collections which multiple threads will work on (if only 1 thread will work on a collection you don't need the concurrency). And use a lock object for things like loading files to ensure you don't load the same thing twice if multiple threads have the potential to do that at the same time.
So no it's not hard.
Oh, well since we were talking about performance, I read what you said as "It's easy to design a multi-threaded program that doesn't use locking".
Plastering locks all over your code is easy, sure, but it hurts performance. That's where it gets more tricky, in my opinion - designing your multi-threaded program to use as little locking (mutexes, semaphores, etc.) as possible.
Its fairly easy to implement multi-threading without locks, there's only one lock in my source. Concurrency and Parallel is where its at, and its not very difficult to make use of those.
Its fairly easy to implement multi-threading without locks, there's only one lock in my source. Concurrency and Parallel is where its at, and its not very difficult to make use of those.
Yeah, sure, you can use the concurrent collections that people from Microsoft with decades of experience in writing lock-free algorithms/data structures made for you, but that's not to say that your program doesn't use locks. Even some of the concurrent collections (ConcurrentBag and ConcurrentDictionary for example) use locking, which means you're still using locking even if you didn't explicitly write the lock statements in your code yourself.
Yeah, sure, you can use the concurrent collections that people from Microsoft with decades of experience in writing lock-free algorithms/data structures made for you, but that's not to say that your program doesn't use locks. Even some of the concurrent collections (ConcurrentBag and ConcurrentDictionary for example) use locking, which means you're still using locking even if you didn't explicitly write the lock statements in your code yourself.
Sure, and if you bother to read up on how specific classes work you can minimise lock statements if they are causing issues. Of course when your using Parallel in conjunction with Concurrent collections your likely not going to find a better combination in terms of performance unless you take it to the extremes and work at extremely low levels.
But like I said its all about your design, Concurrent collections are slower than their regular counterparts so its a trade off as with most design choices. Is it quicker to use the slower collection which scales better across multiple threads, or use the faster collection which isn't thread safe unless you put a bunch of wrapping around it and in turn trade more performance for safety.
Typically if your going to be using alot of multi-threading then Concurrent collections are the way to go, if you know the collection will only ever be accessed by one thread at a time then always pick the standard collection, that's as complicated as it needs to be.
Pirates of Altis 3.1.3 stellt sich vor | WM AKTION | Events | WL Cops&Medics | Events 06/28/2014 - Private Server Advertising - 0 Replies Hallo Community!
Wir, die Pirates of Altis, bestehend aus 10 aktiven Spielern, haben uns entschlossen, einen eigenen Altis Life Server in Betrieb zu nehmen.
Entsprechend ist der Server noch sehr jung, und unterbevölkert, dennoch haben wir schon mehrere Stammspieler gewonnen.
Da wir uns fest vorgenommen haben, mehr zu spielen als zu regieren, können wir sehr schnell Änderungen vornehmen, Fehler finden und beseitigen, sowie die Sicht des Spielers in Problemfällen erkennen. So sollte es,...
Multithreading 10/08/2012 - C/C++ - 25 Replies Guten Tag Leute,
Ich befasse mich seid ca 2 monaten immer mal wd mit c++ und probiere mich dran einfache Programme zu schreiben .
Nun aber wollte ich mich mal am multithreading versuchen da ich eine Schleife programmieren will die solange läuft bis der Benutzer einen button drückt oder Bei der konsole per eingabe die schleife stoppt.
Mir wurde gesagt ich soll eine globale Variable definieren was ich getan habe und dann die schleife in einen Threat packen soll .Mein Problem ist nun aber das...
