While very simple, it will break down if you don't understand a few things:
I print from several places. Bad practice. Printing, and any screen work, is heavy duty stuff.
Hidden threads, changing the destination environment defaults, and back again - lots of stuff going on.
The cpu is far faster than you think. The prints will get in the way of each other. Without pauses, they
won't have time to complete before your thread/sub/function completes - effectively orphaning the print process in the OS. This will drive you crazy if you don't know this.
The input - mouse or keyboard - is also involved.
Typically, only one thread handles all input/output and is 'fed' by any other threads running.
Threads can be started, paused, continued, and killed.
Guards must be in place to protect data, and also to protect the I/O.
Threads can divide and conquer, but only if you understand when they are useful.
You absolutely DO NOT NEED A MULTICORE CPU FOR THREADS. If someone tells you that, they do not know how this all works.
Even - especially - your teachers and the gurus at any programming site. Even FB.
If this were true, Intel would not have sold many billions of single core processors.
First, understand that threads are not free:
it takes time and resource to kick them off - they aren't instant
they aren't completely separate from your program - they 'borrow' a copy of the environment they come from
they MAY speed up execution - if your program can benefit from a parallel process - you still have to wait if you need its result
if your system is too busy - it just got busier
SIMPLE examples of threads:
I want to poll my network to see who is up. I can ping each address in my network. 253 addresses.
Timeout - say two seconds. 253 * 2 = 506 seconds. Over 8 minutes.
Threads. Each pings and waits. My (now retired) single core P4 system would do this in about 5 seconds TOTAL.
EACH thread waits max 2 seconds - all . at . the . same . time -- called concurrent.
If you have a large data table, and a corresponding place to put results, and the same operation can be applied to all data items in the same way, threads can help.
Cost: you have to write all the code to make it happen. If the total count of operations are below a certain (usually not small) amount: just not worth the effort. Depends on the job.
A modern graphics processor works this way.
If you have a lot of independent data processing going on, not lock-stepped to each other, with perhaps one thread waiting for all results, threads may help.
Most game engines work this way.
The rendering engine waits - or maybe doesn't wait - for all the individual components to be updated. Some depend on each other, some do not.
When a clock ticks, the rendering engine displays what is ready - what has been fed to it. Then waits for another clock tick.
Meanwhile, you are fanning the 'FIRE' button to get as many shots off as possible.
One process is logging/consuming your button presses.
One process is managing all those monsters on-screen trying to kill you.
Both those processes are updating the same data representation of the game in a data buffer.
Then - SNAP!
The rendering process clock ticks and a snapshot of that data buffer goes to the screen, all updated.
Oversimplified, but that's what happens.