multithreading vs events

Quote:

Originally Posted by Korvacs And even then none of those are problems if you design your threading correctly.

Pretty much and when you use languages that are designed for concurrency and thread synchronization such as D, Go etc.

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.

Quote:

Originally Posted by Korvacs And even then none of those are problems if you design your threading correctly.

That's probably easier said than done ... a lot easier said than done

Quote:

Originally Posted by EpvpIsAJoke 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.

So no it's not hard.

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.

Quote:

Originally Posted by Korvacs 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.

Quote:

Originally Posted by Korvacs 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.

Quote:

Originally Posted by EpvpIsAJoke 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.