Problem with threads

[iBotx]

Hey guys,
I'm facing a problem figuring out how to work with threads, they seem to be complicated somehow for me. I know how basic threads works but when it comes to multithreading and pooling it becomes complicated. So if someone can explain it briefly or recommend something well explained i'd really appreciate it.

P.S : I DON'T WANT SOMEONE TELLING ME TO GOOGLE IT CAUSE I ALREADY DID IT.

[Spirited]

I'm no professor, but I'll take a stab at it. Alright, so a program is just a sequence of instructions. We can agree on that, right? Well, let's say you represent that sequence of instructions as a string of yarn, and as the processor decodes and executes your instructions, it cuts a bit off your string of yarn until it is completely gone (representing the completion of your program). You with me so far?

So, in the simplest form, the processor is processing instructions from your program and the string is cut shorter and shorter until it's gone (aka. the program has finished executing). Well, in the real world, we have multiple programs executing at the same time. What the processor does to run multiple programs at once is take instructions from one program, execute them, then take instructions from another program, and execute them, and continue that cycle. So, it cuts a bit of yarn off one program, then cuts a bit of yarn off another... and so on. This is where threading comes in. Threading is like creating a second string of yarn in your program; so, instead of having just one string of yarn that the processor cuts a bit from every time it executes instructions, it can cut from two strings. This means you can do things "at the same time". Creating a new thread is just simply creating a second child program inside your existing parent program (just handled a bit different according to the operating system).

Now, you can probably imagine the problem this presents. The more threads you add (let's say 256 threads like how the fucking Trinity shit sources do things these days), the more strings of yarn the processor has to cut from and the slower the process goes. Having too many threads is problematic. To combat that, we now have multi-core processors where two or more processors are cutting off bits of instructions.

Here are some examples of where you'd use multithreading. Let's say you're performing a lot of work to load large amounts of data to a program from file (like loading maps for a Conquer Online private server). You could use multithreading to load maps in parallel - dramatically speeding up your map's load time. Here's another example, if you didn't use threading when handling players on your server, you would only be able to have one person connect at a time. In the simplest form, threads allow each player to have a "string of yarn" to send data to for server processing (like a step or jump). That way, multiple players can be jumping and walking around at the same time. Make sense?

[iBotx]

Originally Posted by Spirited

I'm no professor, but I'll take a stab at it. Alright, so a program is just a sequence of instructions. We can agree on that, right? Well, let's say you represent that sequence of instructions as a string of yarn, and as the processor decodes and executes your instructions, it cuts a bit off your string of yarn until it is completely gone (representing the completion of your program). You with me so far?

So, in the simplest form, the processor is processing instructions from your program and the string is cut shorter and shorter until it's gone (aka. the program has finished executing). Well, in the real world, we have multiple programs executing at the same time. What the processor does to run multiple programs at once is take instructions from one program, execute them, then take instructions from another program, and execute them, and continue that cycle. So, it cuts a bit of yarn off one program, then cuts a bit of yarn off another... and so on. This is where threading comes in. Threading is like creating a second string of yarn in your program; so, instead of having just one string of yarn that the processor cuts a bit from every time it executes instructions, it can cut from two strings. This means you can do things "at the same time". Creating a new thread is just simply creating a second child program inside your existing parent program (just handled a bit different according to the operating system).

Now, you can probably imagine the problem this presents. The more threads you add (let's say 256 threads like how the fucking Trinity shit sources do things these days), the more strings of yarn the processor has to cut from and the slower the process goes. Having too many threads is problematic. To combat that, we now have multi-core processors where two or more processors are cutting off bits of instructions.

Here are some examples of where you'd use multithreading. Let's say you're performing a lot of work to load large amounts of data to a program from file (like loading maps for a Conquer Online private server). You could use multithreading to load maps in parallel - dramatically speeding up your map's load time. Here's another example, if you didn't use threading when handling players on your server, you would only be able to have one person connect at a time. In the simplest form, threads allow each player to have a "string of yarn" to send data to for server processing (like a step or jump). That way, multiple players can be jumping and walking around at the same time. Make sense?

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.

[Spirited]

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.

[Best Coder 2014]

Originally Posted by Spirited

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".

There is actually a big difference between a "managed" and an "unmanaged" (operating system) thread:

Note: An operating-system ThreadId has no fixed relationship to a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. Specifically, a sophisticated host can use the Fiber API to schedule many managed threads against the same operating system thread, or to move a managed thread among different operating system threads.

From: .

Originally Posted by Spirited

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.

This can be done without a thread pool as well. The only purpose of a thread pool is really just to be able to re-use threads instead of having to constantly create new threads, which is somewhat expensive.

Originally Posted by Spirited

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).

"fork" is just UNIX terminology for creating a new (cloned) process, it doesn't have anything to do with threads. I think it's easier to just look at a process as a collection of threads (which can execute "simultaneously"), since that's what it basically is: a process consists of either one or more threads, and all the threads in a process share the same memory. Then, creating a thread is simply just adding a new thread to this collection of threads.

[iBotx]

Thanks guys !

[Spirited]

Originally Posted by Best Coder 2014

There is actually a big difference between a "managed" and an "unmanaged" (operating system) thread:

From: .

This can be done without a thread pool as well. The only purpose of a thread pool is really just to be able to re-use threads instead of having to constantly create new threads, which is somewhat expensive.

"fork" is just UNIX terminology for creating a new (cloned) process, it doesn't have anything to do with threads. I think it's easier to just look at a process as a collection of threads (which can execute "simultaneously"), since that's what it basically is: a process consists of either one or more threads, and all the threads in a process share the same memory. Then, creating a thread is simply just adding a new thread to this collection of threads.

I hold my position, besides the thread pool. You can have that one.

[KraHen]

Originally Posted by Spirited

I hold my position, besides the thread pool. You can have that one.

His first point is valid. His second point is valid. His third point is essentially what you said, just expressed simpler, also valid.

[Spirited]

Originally Posted by KraHen

His first point is valid. His second point is valid. His third point is essentially what you said, just expressed simpler, also valid.

I'm not saying his point isn't valid. I'm just saying I stand on mine. I take the bell labs approach, not the Microsoft approach. You're not going to go to a research university and learn about "managed" and "unmanaged" threads because they're not a thing outside of Microsoft-land.