Working driver is a process of OS or not? Wiki says „Process is an instance of a computer program that is being executed“, but dll is not a process. In other side, driver have virtual memory, stack and so on like a process, but for opening we use CreateFile/fopen.
In general, no. Drivers, (at least partially), don't have a process context because they are given execution by hardware interrupts that transfer execution from currently running processes.
Multi-level drivers can, and do, have threads/processes as support, but the lowest levels cannot be considered processes/threads.
Related
In a computer system, the ISA level is lower than the OS level. The OS level is built upon the ISA level.
At the OS level, different programs run in different processes.
A program can run before another program finishes running, by context switching.
Programs in different processes do not affect each other.
Assume there is no OS and there is only one cpu core in the computer system. At the ISA level, there does not exist the concept of process. what is it like to run different programs?
must a program start to run after the previous program finishes running?
can the previous finished program affect the following program, in an untended or intended way?
The question "what is it like" sounds like a question about how the processor feels about running the instructions it is given. It just runs them.
It is not true entirely that there wouldn't be a concept of a process on ISA level. Processors may have hardware support for task switching, so they might actually know about them. Of course the OS will still be running the show.
Simply put, at the ISA level the software meets the hardware. So the single core CPU will just churn instructions and command peripherals from a preset memory location onwards until it's turned off or halts otherwise. Is there some other specific question about "what is it like"?
I am just now learning about OSes and I stumbled upon this question from my class' lecture notes. In our class, we define a process as a program in execution and I know that an OS is itself a program. So by this definition, an OS is a process.
At the same time processes can be switched in or out via a context switch, which is something that the OS manages and handles. But what would handle the OS itself when it isn't running?
Also if it is a process, does the OS have a process control block associated with it?
There was an older question on this site that I looked at, but I felt as if the answers weren't clear enough to really outline WHY the OS is/isn't a process so I thought I'd ask again here.
First of all, an OS is multiple parts. The core piece is the kernel, which is not a process. It is a framework for running processes. In practice, a process is more than just a "program in execution". On a system with an MMU, a process is usually run in its own virtual address space. The kernel however, is usually mapped into all processes. It's always there.
Other ancillary parts of the OS exist to make it usuable. The OS may have processes that it runs as part of its management. For example, Linux has many kernel threads that are independently scheduled tasks. But these are often not crucial to the OS's operation.
Short answer: No.
Here's as good a definition of "Operating System" as any:
https://en.wikipedia.org/wiki/Operating_system
An operating system (OS) is system software that manages computer
hardware and software resources and provides common services for
computer programs. The operating system is a component of the system
software in a computer system. Application programs usually require an
operating system to function.
Even "system-level processes" (like "init" on Linux, or "svchost.exe" on Windows) rely on the "operating system" ... but are not themselves the operating system.
Agreeing to some of the comments above/below.
OS is not a process. However there are few variants in design that give the opposite illusion.
For eg: If you are running a FreeRTOS, then there is no such thing as a separate OS address space and Process address space, every thing runs as a single process, the FreeRTOS framework provides API's that allow Synchronization of different tasks.
Operating System is just a set of API's (system calls) and utilities that help to achieve Multi-processing, Resource sharing etc. For eg: schedule() is a core OS function that handles the multi-processing capabilities of the OS.
In that sense, OS is not a process. Although it attaches to every process that runs on the CPU, otherwise how will the process make use of the OS's API.
It is more like soul for the body (hardware), if you will.
It is just not one process but a set of (kernel) processes required to run user processes in the system. PID 0 being the parent of all processes providing scheduler/swapping functionality to the rest of the kernel/user processes, but it is not the only process. These kernel processes (with the help of kernel drivers) provide accessor functionality (through system calls) to the user processes.
It depends upon what you are calling the "operating system".
It depends upon what operating system you are talking about.
That said and at the risk of gross oversimplification, most of what one calls "the operating system" is generally executed from user processes while in kernel mode. The entry into kernel occurs either through an interrupt, trap or fault.
To do a context switch usually either a process causes a fault entering kernel mode to so something (like write to the disk). While in kernel mode, the process realizes it would have to wait so it yields by switching the context to another process. The other common way is a timer causes an interrupt, that forces the process into kernel mode. The process then determines who should be executed next, and switches the process context.
Some operating systems do have their own kernel process that function but that is increasingly rare.
Most operating system have components that have their own processes.
I am recently develop a big interest to learn about operating systems and I have been studying about this topic, I have a question that I am not pretty sure if is a valid one.
I am aware that the OS is the one who controls the process but,
is the OS a process itself? If so, who controls the OS?
Sorry for my ignorance I am learning about operating system and I am trying to have a solid idea about how it works.
Thanks in advance.
The term OS comes with some ambiguities... Does the user interface count as the OS? What about software that reads file systems?
The Kernel is generally the most important aspect of an Operating System. The Kernel is responsible for scheduling threads and processes, as well as abstracting the hardware from the software. The kernel itself is NOT a process, but it is a program. It's a program that always exists in every process space. When a process needs to access hardware, the kernel takes over and returns a response to the process. When the process's allotted time on the CPU is over, the kernel takes over and gives the CPU to a new process.
Other aspects of an Operating System, however, are their own processes. For example, on Windows, the user interface and many background services are their own processes. On Linux and other UNIX-like operating systems, the User Interfaces are also in their own respective processes, and in some cases things like filesystem drivers are in their own process as well, sometimes this is considered a hardware abstraction and is therefore placed in the kernel.
There are many possible design choices, however when it comes down to it there will always be a part of the operating system (the Kernel) that will never be it's own process.
The OS is a bunch of processes. It is started up during the boot process. How the boot process works depends on the system. But generally, the boot process is also a process whose sole job is to start up the OS.
The OS is generally specific to the hardware it runs on. A main function of the OS is to be a layer between the hardware and application programs. Which processes in the OS are used depend on what functions the application programs need to do.
It depends on design approaches.
According to 3.5 section of "Operating Systems Internal and Design Principles - 7th edition" textbook (written by William Stalling), there are 3 approaches:
non-process kernel.
In this approach, user process and kernel are separate.
process image = address space + PCB = (code + data + stack + heap) + PCB
Execution within User Process
In this approach, some common functions of Operation Systems (run in kernel mode) belong to User processes.
process image = PCB + user address space + kernel address space = PCB + (user code + user data + user stack + user heap) + (kernel code + kernel data + kernel stack + kernel heap).
Process-Based Operating System.
In this approach Operating System is a collection of system processes, each system process executes in kernel mode, and is in charge of specific function.
In addition, these system processes separate with user processes.
Best Regards
Viet Nam.
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?
I saw this question somewhere
Four processes p1, p2, p3, p4 - each have sizes 1GB, 1.2GB, 2GB, 1GB. And each processes is executed as a time sharing fashion. Will they be executed on an operating system.
I think the answer should be No,they are not executed on operating system because OS is itself a process and it will be running in parallel to these processes.There will be switching between processes from time to time with the help of dispatcher.
but i am getting the doubt that answer can also be yes because it uses every process uses memory which is managed by theb operating system .
please help me figure out the right answer for the question..
This depends entirely on the OS in question.
As well as starting processes (and possibly consisting of processes), an operating system generally provides services to the processes that run on it, such as memory management, file systems, communications and so on.
In that context, these processes can be said to be running on top of the OS. In other words, processes generally are of little use unless they communicate outside of themselves.
In any event, the dispatcher (or scheduler) tends to be an integral part of the OS so having your processes scheduled means that you're running on top of that OS.
Modern operating systems also provide paging of memory as well which means that you can use a lot more virtual memory than there is physical memory - the OS is then responsible for handling requests for memory that has been paged out.
If two processes co exist, they have their own share of memory. What we assume operating system does is scheduling. Operating system may ask one of the process to stop and another to begin