What does it mean to join a thread ?
Hi,
Could you please explain how threads work exactly ?
what does it mean to join a thread ?
what are thread races ?
what are they used for ?
how can one master their use ?
thanks in advance. :)
Could you please explain how threads work exactly ?
what does it mean to join a thread ?
what are thread races ?
what are they used for ?
how can one master their use ?
thanks in advance. :)
Threads are separate lines of execution. As a basic idea (not quite correct but good enough for the example), imagine that each CPU core is one thread. When you have two threads, it means that each CPU core is working independently of each other. However, they aren't different processes - they are part of the same process, and hence the operating system lets them share some memory.
Joining a thread is a fairly bad term, but it is the process of you finishing a thread. I guess you could look at it as the threads line of execution 'joining' the originator thread's.
Due to threads sharing memory and resources, it means that sometimes two threads will try to modify something at the same time. This leads to data races, such as where one thread reads some data while it is being overwritten, leading to half-incorrect data. There are numerous other things that can occur too, as well as being very difficult to debug, making multithreading a notoriously difficult topic.
Threads are used for a variety of different things. They can be used as a way of speeding up complex calculations, by getting separate threads to do parts of the calculation and getting the final results once all the worker threads are done. They can also be used in something like a UI environment as a way of shifting some work off the event queue, so that the window remains responsive while the work is being done. These are just a few of the possibilities.
To 'master' the use of threading, practice is really what it takes. Read a good book on multithreading, and also learn what kind of things should be done with threads and what shouldn't. Just be warned that they are very difficult to use well.
Joining a thread is a fairly bad term, but it is the process of you finishing a thread. I guess you could look at it as the threads line of execution 'joining' the originator thread's.
Due to threads sharing memory and resources, it means that sometimes two threads will try to modify something at the same time. This leads to data races, such as where one thread reads some data while it is being overwritten, leading to half-incorrect data. There are numerous other things that can occur too, as well as being very difficult to debug, making multithreading a notoriously difficult topic.
Threads are used for a variety of different things. They can be used as a way of speeding up complex calculations, by getting separate threads to do parts of the calculation and getting the final results once all the worker threads are done. They can also be used in something like a UI environment as a way of shifting some work off the event queue, so that the window remains responsive while the work is being done. These are just a few of the possibilities.
To 'master' the use of threading, practice is really what it takes. Read a good book on multithreading, and also learn what kind of things should be done with threads and what shouldn't. Just be warned that they are very difficult to use well.
NT3 did a great job but I'd like to add that in order to "master multi-threading", planning and foresight are just as, if not more, important then practice. Any time you have a process that is performing two completely independent tasks you should consider multi-threading. My favorite go-to example is a video game; you have the main thread performing the running loop that evaluates input, keeps track of the player blah blah blah and another thread playing the sound track. These two tasks are part of the process as a whole, and they do share some data since different areas often have different music and ideally you wouldn't want the music from the last area still going when the player transitions to a new area or skips the current track. But otherwise they are largely independent of each other and can be run concurrently.
The main thing to remember about threads is that they are not a silver bullet solution to every task. Creating a thread involves an overhead cost and with a lot of tasks it is often faster to use a single thread to process a thousand small jobs then it would be to create a thousand threads and process them all side by side. Again, planning is a big part of using threads effectively. To give you an idea of what this "cost" might be, think of creating a new thread as falling somewhere between a function call and spawning a child process. Just because you might hear it elsewhere from some pedantic hipster I'll mention that there is also a very small performance cost involved in switching between active thread contexts. But realistically if you're at the point of considering this impact on your processes performance then you should upgrade your hardware.
The main thing to remember about threads is that they are not a silver bullet solution to every task. Creating a thread involves an overhead cost and with a lot of tasks it is often faster to use a single thread to process a thousand small jobs then it would be to create a thousand threads and process them all side by side. Again, planning is a big part of using threads effectively. To give you an idea of what this "cost" might be, think of creating a new thread as falling somewhere between a function call and spawning a child process. Just because you might hear it elsewhere from some pedantic hipster I'll mention that there is also a very small performance cost involved in switching between active thread contexts. But realistically if you're at the point of considering this impact on your processes performance then you should upgrade your hardware.
Topic archived. No new replies allowed.