Quote:
Originally Posted by iBotx
Okay that seems cool. But what about thread pooling, safe threads, managed threads etc..
Would you recommend something, i'd like to be a professional dealing with threads.
|
Oh, my bad. Glanced over the thread because I was in a hurry this morning. All of those are just flaccid bullshit terms for "thread". In fact, a well known software firm, Bell Laboratories (the writers of Unix and Plan9), made a bullshit generator for generating random programming bullshit. It's fantastic.
Let's start down the line: threading pool is just a case of parallelism where more than one thread work in parallel to perform a task. For example, I use a map of threads in my private server's socket system for processing packets from the clients. Safe threads and managed threads are just more bullshit. They're just threads, and there's no meaning behind it. People who try to make them a definition don't understand how operating systems and programming languages work, and need to stop. I think "managed threading" might also be some Microsoft marketing crap for "let's manage the way you create threads", which is what every other language does as well because it all has to interface with the operating system (also not to be confused with managing threads). Microsoft is full of it, so don't worry about that crap. A thread is a thread.
Moving on, there are different programming paradigms for implementing threads. Regardless of implementation, they all boil down to something called a fork (I've already talked about this, when the parent process creates a new child process to do work on). A thread is simply a lightweight child process for the parent process created by that fork. No matter what you do, it will all amount to a fork and that new thread (eventually).
Regarding programming designs which involve threading, there are many. Many that I don't know of, many that I don't want to know of, etc. Some people like a lot of threads (which is horrible on performance, by the way), making tons of threads to execute work. Some threads are delayed for later processing, some are higher priority for immediate work... etc. That's a horrible design but used and necessary in a lot of web programming (delayed responses). Really alright for applications where high-latency is acceptable. Anyways, there are also the people who like a very minimal amount of threads (just enough to perform optimally on the system it is designed for). Then, there are a lot of different design patterns (another bullshit word for "ways") which stem from these two methodologies.
In the example of my socket system, I use structures which share a concurrent queue (meaning thread-safe, can be accessed across multiple threads without creating read and write conflicts) across my parallel threads (parallelism). That would be an example of multi-threading in a high performance application. Now, from the same example, I have a scheduler thread that executes server tasks in a loop every thirty seconds. This thread would not be an example of parallelism, as I'm just creating a one-off thread to perform a task in a loop. This is the classic and most simple example of using a thread. Simple game engines have this basic idea of a scheduler as well (a thread which loops a function for handling when to paint to the window, update game logic, initialize game structures, etc).
So, there are a lot of different implementations for threads. Really, you should make more of an attempt to look up some more examples based on what I've said and do some research. That's how you're going to get into this kinda stuff. The more you research, the more resourceful you'll become.