According to my understanding one operation is operated by one CPU. And, multiprocessing systems have multiple CPUs. That is, multiprocessing systems can work on multiple tasks at the same time.
But, in multiprocessing systems, only one process is in working state at a point of time.
And processes are alternately performed by process scheduling.
So multiprocessing systems can work on multiple processes at the same time.
Why multiprocessing systems that have multiple CPUs use process scheduling and perform only one process at once by using one CPU?
Why don't multiple CPUs perform multiple processes at the same time?
Why multiprocessing systems that have multiple CPUs use process scheduling and perform only one process at once by using one CPU?
Most systems these days use THREAD scheduling; not process scheduling. There are still some Eunuchs variants that still schedule processes but most have switched to threads.
Why don't multiple CPUs perform multiple processes at the same time?
They do. They also execute multiple threads in the same process at the same time.
Related
As far as I know,
GPU can simultaneously run thousands of threads that belong to one GPU kernel process, and that is the reason why it called SIMT.
However, can GPGPU simultaneously run multiple threads that belong to different GPU kernel processes? If possible, does it mean that those threads can run on one of GPU cores, and multiple cores can run simultaneously? Or does it mean that even one GPU core can run multiple threads belongs to different kernels?
Or simply, is it only possible to run threads that belong to the same GPU kernel process at a time on the entire GPU cores?
"Processes may be described as physically concurrent and logically
concurrent processes, the distinction between them is analogous to
that between real and virtual processors"
what does that mean?
What is the difference between physically concurrent and logically concurrent processes?
What is the difference between physically concurrent and logically
concurrent processes?
Suppose if you've a single core processor, and suppose if you have multithreading in your code, it'll show as if it is running in parallel in multiple different processors; but, in reality it utilises the single processor, where quantum of time is allotted to each threads in round-robin manner. In this case, the processes(OR threads) seem to be running in parallel concurrently, but, in reality, there is context switch many-a-times between the processes(threads) to simulate as if they are running simultaneously.
Whereas, had you been having multiple cores in your processor(or multiple processors), your multithreaded code would have executed in parallel on different cores(or processors, if there) concurrently! In this case, the processes are running in parallel concurrently.
I hope it clears your doubt! Feel free to ask in case of further queries.
This is an interview question I encountered today. I have some knowledge about OS but not really proficient at it. I think maybe there are limited threads for each process can create?
Any ideas will help.
This question can be viewed [at least] in two ways:
Can your process get more CPU time by creating many threads that need to be scheduled?
or
Can your process get more CPU time by creating threads to allow processing to continue when another thread(s) is blocked?
The answer to #1 is largely system dependent. However, any rationally-designed system is going to protect again rogue processes trying this. Generally, the answer here is NO. In fact, some older systems only schedule processes; not threads. In those cases, the answer is always NO.
The answer to #2 is generally YES. One of the reasons to use threads is to allow a process to continue processing while it has to wait on some external event.
The number of threads that can run in parallel depends on the number of CPUs on your machine
It also depends on the characteristic of the processes you're running, if they're consuming CPU - it won't be efficient to run more threads than the number of CPUs on your machine, on the other hand, if they do a lot of I/O, or any other kind of tasks that blocks a lot - it would make sense to increase the number of threads.
As for the question "how many" - you'll have to tune your app, make measurements and decide based on actual data.
Short answer: Depends on the OS.
I'd say it depends on how the OS scheduler is implemented.
From personal experience with my hobby OS, it can certainly happen.
In my case, the scheduler is implemented with a round robin algorithm, per thread, independent on what process they belong to.
So, if process A has 1 thread, and process B has 2 threads, and they are all busy, Process B would be getting 2/3 of the CPU time.
There are certainly a variety of approaches. Check Scheduling_(computing)
Throw in priority levels per process and per thread, and it really depends on the OS.
I believe I have a reasonable understanding of threading from an Object Oriented perspective using the Thread class and the Runnable interface. In one of my applications there is a "download" button that allows the user to run a task in the background that takes about half an hour whilst continuing to use the VB.NET application.
However, I do not understand how Threading maps to the physical architecture of a computer. If you have a single threaded application that runs on a PC with a quadcore processor then does a .net program use all four processors?
If you have a multi threaded application (say four threads) on a quadcore processor then does each thread execute on different cores?
Do you have any control of this as a developer?
I have referenced a book I read at university called Operating System Concepts, but I have not found a specific answer.
If you have a single threaded application that runs on a PC with a quadcore processor then does a .net program use all four processors?
No, it can’t, at least not simultaneously. However, it’s theoretically possible that the operating system’s scheduler first executes your thread on one processor and later moves it to another processor. Such a scheduler is necessary to allow simultaneously running more applications / threads than there are physical processors present: execution of a thread is sliced into small pieces, which are fed to the processor(s) one after the other. Each threads gets some time slice allocated during which it can calculate before usage of the CPU switches to another thread.
Do you have any control of this as a developer?
Not directly. What you can control is the priority of your thread to make it more important to the task scheduler.
On a more general note, you should not use threads in your use-case – at least not directly. Threads are actually pretty low-level primitives. For your specific use-case, there’s a component called BackgroundWorker which abstracts many of the low-level details of thread management for you.
If you have a multi threaded application (say four threads) on a quadcore processor then does each thread execute on different cores?
Not necessarily; again, the application has next to no control over how exactly its threads are executed; the operating system however tries really hard to schedule threads “smartly”. This means that in practice, if your application has several busy threads, they are spread out as evenly as possible across the available cores. In particular, if there are no more threads than cores then each thread gets its own core.
Generally, you do not need to worry about mapping to physical architecture, .NET and the OS will do their best to maximize efficiency of your application. Just make it multi-threaded, even at the cost of being slower on a single threaded computer. You can, however, limit your maximum number of threads (if your app theoretically scales to infinity), to a number of cores, or double that. Test performance for each case, and decide which maximum works best for you.
Sometimes setting a core # can make your app's performance even worse. For example, if core #1 is currently scanning your PC for viruses, and your antivirus is single threaded. With the above scenario, assuming a quad-core PC, you do NOT want to run your 4-threaded app on a 1-per-core basis.
Having said that, if you really want to run a thread on specific core, it is possible - see this:
How to start a Thread at Specific Core
How Can I Set Processor Affinity in .NET?
Also check this out:
How to control which core a process runs on?
What is the difference between a thread/process/task?
Process:
A process is an instance of a computer program that is being executed.
It contains the program code and its current activity.
Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently.
Process-based multitasking enables you to run the Java compiler at the same time that you are using a text editor.
In employing multiple processes with a single CPU,context switching between various memory context is used.
Each process has a complete set of its own variables.
Thread:
A thread is a basic unit of CPU utilization, consisting of a program counter, a stack, and a set of registers.
A thread of execution results from a fork of a computer program into two or more concurrently running tasks.
The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process. Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.
Example of threads in same process is automatic spell check and automatic saving of a file while writing.
Threads are basically processes that run in the same memory context.
Threads may share the same data while execution.
Thread Diagram i.e. single thread vs multiple threads
Task:
A task is a set of program instructions that are loaded in memory.
Short answer:
A thread is a scheduling concept, it's what the CPU actually 'runs' (you don't run a process). A process needs at least one thread that the CPU/OS executes.
A process is data organizational concept. Resources (e.g. memory for holding state, allowed address space, etc) are allocated for a process.
To explain on simpler terms
Process: process is the set of instruction as code which operates on related data and process has its own various state, sleeping, running, stopped etc. when program gets loaded into memory it becomes process. Each process has atleast one thread when CPU is allocated called sigled threaded program.
Thread: thread is a portion of the process. more than one thread can exist as part of process. Thread has its own program area and memory area. Multiple threads inside one process can not access each other data. Process has to handle sycnhronization of threads to achieve the desirable behaviour.
Task: Task is not widely concept used worldwide. when program instruction is loaded into memory people do call as process or task. Task and Process are synonyms nowadays.
A process invokes or initiates a program. It is an instance of a program that can be multiple and running the same application. A thread is the smallest unit of execution that lies within the process. A process can have multiple threads running. An execution of thread results in a task. Hence, in a multithreading environment, multithreading takes place.
A program in execution is known as process. A program can have any number of processes. Every process has its own address space.
Threads uses address spaces of the process. The difference between a thread and a process is, when the CPU switches from one process to another the current information needs to be saved in Process Descriptor and load the information of a new process. Switching from one thread to another is simple.
A task is simply a set of instructions loaded into the memory. Threads can themselves split themselves into two or more simultaneously running tasks.
for more Understanding refer the link: http://www.careerride.com/os-thread-process-and-task.aspx
Wikipedia sums it up quite nicely:
Threads compared with processes
Threads differ from traditional multitasking operating system processes in that:
processes are typically independent, while threads exist as
subsets of a process
processes carry considerable state information, whereas multiple
threads within a process share state
as well as memory and other resources
processes have separate address spaces, whereas threads share their
address space
processes interact only through system-provided inter-process
communication mechanisms.
Context switching between threads in the same process is
typically faster than context
switching between processes.
Systems like Windows NT and OS/2 are said to have "cheap" threads and "expensive" processes; in other operating systems there is not so great a difference except the cost of address space switch which implies a TLB flush.
Task and process are used synonymously.
from wiki clear explanation
1:1 (Kernel-level threading)
Threads created by the user are in 1-1 correspondence with schedulable entities in the kernel.[3] This is the simplest possible threading implementation. Win32 used this approach from the start. On Linux, the usual C library implements this approach (via the NPTL or older LinuxThreads). The same approach is used by Solaris, NetBSD and FreeBSD.
N:1 (User-level threading)
An N:1 model implies that all application-level threads map to a single kernel-level scheduled entity;[3] the kernel has no knowledge of the application threads. With this approach, context switching can be done very quickly and, in addition, it can be implemented even on simple kernels which do not support threading. One of the major drawbacks however is that it cannot benefit from the hardware acceleration on multi-threaded processors or multi-processor computers: there is never more than one thread being scheduled at the same time.[3] For example: If one of the threads needs to execute an I/O request, the whole process is blocked and the threading advantage cannot be utilized. The GNU Portable Threads uses User-level threading, as does State Threads.
M:N (Hybrid threading)
M:N maps some M number of application threads onto some N number of kernel entities,[3] or "virtual processors." This is a compromise between kernel-level ("1:1") and user-level ("N:1") threading. In general, "M:N" threading systems are more complex to implement than either kernel or user threads, because changes to both kernel and user-space code are required. In the M:N implementation, the threading library is responsible for scheduling user threads on the available schedulable entities; this makes context switching of threads very fast, as it avoids system calls. However, this increases complexity and the likelihood of priority inversion, as well as suboptimal scheduling without extensive (and expensive) coordination between the userland scheduler and the kernel scheduler.