What's some of the reasons you would need to use threads?
closed account (zb0S216C)
Here's a quick scenario: When two or more methods require parallel execution.
When working with threads, be careful of dead-locks. Dead-lock is a term used in computing when one thread waits on another, which waits on the other one. For example: Thread A is waiting for Thread B to finish. However, Thread B is waiting for Thread A to finish. In this scenario, none of the threads will ever stop.
Wazzak
When working with threads, be careful of dead-locks. Dead-lock is a term used in computing when one thread waits on another, which waits on the other one. For example: Thread A is waiting for Thread B to finish. However, Thread B is waiting for Thread A to finish. In this scenario, none of the threads will ever stop.
Wazzak
Last edited on
1. if you are running a single-threaded application and you are CPU-bound on a multi-core CPU, having multiple threads may be useful (provided that you write your app correctly) - this is particularly applicable in recent years as CPU clock speeds have not increased, but the number of cores per CPU has
2. if you make calls to a blocking function that waits for completion (like from a socket or stdin from an end-user), that may be a good candidate for a thread as other threads continue to do work in the background
3. usually, threads are lighter-weight than other methodologies, like forking another process
4. if your algorithm has independent pieces that don't depend on each other and don't depend on previous state - it may be a good candidate for multithreading
but you never really need to use threads - I think there are few apps that cannot be written to work under a single thread... (except maybe case 2. above)
edit: also, if you do not have threads, there are alternatives such as interrupts or event-loops, which may make it appear as if your app is doing more than one thing at a time
2. if you make calls to a blocking function that waits for completion (like from a socket or stdin from an end-user), that may be a good candidate for a thread as other threads continue to do work in the background
3. usually, threads are lighter-weight than other methodologies, like forking another process
4. if your algorithm has independent pieces that don't depend on each other and don't depend on previous state - it may be a good candidate for multithreading
but you never really need to use threads - I think there are few apps that cannot be written to work under a single thread... (except maybe case 2. above)
edit: also, if you do not have threads, there are alternatives such as interrupts or event-loops, which may make it appear as if your app is doing more than one thing at a time
Last edited on
I've only used threads once when I made a multi client game linked through a server, but in general you need seperate threads when you need more than one thing to happen in parallel.
Examples are:
If a blocking call to a function must be made, which means that execution stops until some event has occured, then a new thread must be created for this task so that other parts of the program are not halted.
If data can is received asynchonously (at any time) then a new thread must be started to receive this data as just checking for this data once per game loop could miss the data.
EDIT - Too Slow
Examples are:
If a blocking call to a function must be made, which means that execution stops until some event has occured, then a new thread must be created for this task so that other parts of the program are not halted.
If data can is received asynchonously (at any time) then a new thread must be started to receive this data as just checking for this data once per game loop could miss the data.
EDIT - Too Slow
Last edited on
closed account (zb0S216C)
In addition to Kfmfe's post, multi-threading in single-core CPU is allowed. In single-core CPUs, the term Context Switching is used. Context Switching is when the CPU executes one thread for a certain amount of time, saves it's state, executes another thread for a certain amount of time, saves it's state, then resumes execution of the previous thread. This happens so frequently, it's appears as though the threads are running simultaneously.
In multi-core CPUs however, depending on the amount of execution cores the CPU has( 2, for example ), the CPU has ability to execute two threads simultaneously( including Context Switching ).
Note that each thread has it's own Program Counter( this is a register in the CPU that points to the next instruction to be executed by the CPU ), it's own 1MB( default size ) stack, and it's own registers.
I'm telling you all of this because it's important to know what threads are, and how they work.
Wazzak
In multi-core CPUs however, depending on the amount of execution cores the CPU has( 2, for example ), the CPU has ability to execute two threads simultaneously( including Context Switching ).
Note that each thread has it's own Program Counter( this is a register in the CPU that points to the next instruction to be executed by the CPU ), it's own 1MB( default size ) stack, and it's own registers.
I'm telling you all of this because it's important to know what threads are, and how they work.
Wazzak
Last edited on
regarding Framework's comment on deadlocks, they usually happen when there are multiple mutexes, but no consistent ordering for the locks; when deadlocks happen, the cause is usually obvious and requires a clear reevaluation of the ordering policy for locks
far more insidious and time-consuming (in terms of debugging) are race-conditions
race conditions lead to sporadic behavior during run-time and may actually be far from obvious - identifying race conditions with certainty often requires some experience along with run-time tools which may only identify possible race conditions should your run happen to go through those chunks of code this time around
possibility of race conditions due to sharing of mutable resources (like memory) without locks is one of the major reason for using various alternative paradigms for multithreading such as message passing and multithreading agents
also, context switches can happen at any time, including on multi-core CPUs - consider that the OS is running many different processes, each with one or more threads - the OS itself needs to appropriate a finite (and often, small) number of cores to a multitude of processes/threads
increasing likelihood of context switches is a major reason for not spawning 10,000 threads "to make your app run faster" when you only have a 2 core CPU
think about it - without hyperthreading, the OS has to decide which 2 of the 10,000 threads it needs to run right now, while blocking all the other ones! and then, a few cycles later, block those 2 threads and run two other threads - every time, doing context switches, which may be relatively cheap per switch, but not when you do them too frequently!
far more insidious and time-consuming (in terms of debugging) are race-conditions
race conditions lead to sporadic behavior during run-time and may actually be far from obvious - identifying race conditions with certainty often requires some experience along with run-time tools which may only identify possible race conditions should your run happen to go through those chunks of code this time around
possibility of race conditions due to sharing of mutable resources (like memory) without locks is one of the major reason for using various alternative paradigms for multithreading such as message passing and multithreading agents
also, context switches can happen at any time, including on multi-core CPUs - consider that the OS is running many different processes, each with one or more threads - the OS itself needs to appropriate a finite (and often, small) number of cores to a multitude of processes/threads
increasing likelihood of context switches is a major reason for not spawning 10,000 threads "to make your app run faster" when you only have a 2 core CPU
think about it - without hyperthreading, the OS has to decide which 2 of the 10,000 threads it needs to run right now, while blocking all the other ones! and then, a few cycles later, block those 2 threads and run two other threads - every time, doing context switches, which may be relatively cheap per switch, but not when you do them too frequently!
Last edited on
Topic archived. No new replies allowed.