Quote:
Originally Posted by
jimthompson
Q1. Is multi threading a hardware / chip level concept, an OS level or an application level concept ? I am trying to work out where SMT architecture fits in.
It's both -- and simpler than you think. Everything the CPU runs is a thread. Even a single thread is a thread! Time-slicing, pre-emption, all the usual rules still apply, even on multi-core. A store with several checkouts still sees lineups when its busy enough.
What I need to clear up, I think, is what "process" and "thread" actually mean. A process is a set of memory, open files, sockets, and one or more threads. A thread is a copy of a CPU's registers. Load it into any of the system's cores and that CPU will execute instructions from wherever it left off. When the thread is stopped, the registers are copied into memory, saved for later.
"Multithreading" means the ability to have several threads running in the same process. This means two CPU's simultaneously operating on the
exact same memory, files, and sockets. Literally the exact same. Open a file in one thread, any other thread in the same process can use it by calling read() with the right file descriptor number.
This has some benefits. Having a set of files and sockets for every thread can be wasteful of memory, and if your processes are communicating with each other a lot, they may spend more time sending to and receiving from other processes than doing actual work. Since every system call is a pre-emption by definition (the thread stops while the kernel runs), this can mean a lot of pointless waiting for each other as well.
Two threads in the same process have access to all the same resources. This makes communication direct and fast, and makes some things easy which used to be nearly impossible -- imagine trying to send a file
descriptor to another process -- very difficult. Another thread, though? Being in the same process, it's already valid.
It also has its problems. Each thread is scheduled independently, so you can't assume you always get the order you wanted. A common beginner mistake is to run a thread, immediately return from main (terminating the process and killing all threads) then wonder why the thread never finished. You also have to worry about race conditions -- if two threads write to the same variable at the exact same cycle, which wins? There are many books filled with this subject.
Quote:
Q2. What’s the multi threading position in relation to Unix, Linux and Windows ?
Linux threading used to be very eccentric -- it joined several single-threaded processes together instead of keeping several threads in one process. They replaced that with something POSIX-complaint now. Windows threading is more similar to UNIX threading than Windows processes are to UNIX processes, at least. It's hard for it to be that different when the concept is so similar. It's done through different calls, though.
Quote:
Q3. Is multi threading only in relation to application processes or is it for OS processes as well ?
Every CPU state is a thread, so kernels have threads.
Since the kernel is the thing which makes processes possible, it might even be thought to have threads without processes.
Quote:
I am trying to differentiate multi threading from the older CPU concepts of timeslicing, round robin etc
All these concepts still apply.
Quote:
My understanding is that you can have multi processing systems which switch between or execute processes in parallel. However multi threading takes this a step further in that a process can be broken down into threads and the processor execute the individual threads ( again via switching or parallel depending on the number of processors / cores you have )
Again, threads are what actually get scheduled. Otherwise, the rules are exactly the same.
Quote:
Q4. Are processors therefore specifically designed either to execute full processes, threads or both ?
This is a non-sequitur, the thread is what gets executed, the process is the context it runs in.
But in a manner of speaking -- both. Nearly any modern CPU handles memory management in hardware, and that's a big chunk of what needs to be done to manage a process.
Quote:
Can a single processor execute a mix of full processes and threads ? i.e. does a processor operate only at either a process level or a thread level ?
This is
almost a simple question to answer... One core is one CPU, one CPU runs runs one thread, and everything is a thread.
Except, Hyperthreading processors can
sometimes overlap two threads on one CPU. They have to be doing independent, non-overlapping things -- one could add two registers while another reads something memory, all on one CPU. This needs the help of the operating system, so a quad-core hyperthreading processor might appear to have 8 cores, but acts more like a 4-core which runs more instructions per clock cycle.
Quote:
Q5. What’s the difference between a single processor with multi cores and a multi processor with single core processors ?
One core is still one thread. Putting several cores on one chip is faster in some ways -- they can communicate directly, and share the same cache -- and slower in others. Imagine two cores fighting over one memory channel, versus two chips using two different buses.
Quote:
Q6. Are most modern processors today, multi thread capable processors ( or is it the OS which determines this ).
Any multi-core CPU supports it by definition, which these days is most consumer CPU.. A 64-bit PC has a CPU derived or cloned from AMD's Opteron chips, which were designed for several cores per chip from the beginning. Even before that, everything later than the Pentium was technically
capable of it, except most boards didn't actually have multiple CPU's to take advantage of it.