Yesterday i understood in my Advanced Operating Systems class that there will be a limit in the number of processes that can be allowed to be placed in the Ready Queue.I would like to know that number for different operating systems.And also what happens when that number is exceeded? Meaning : what if more than that number of processes are created?
I tried to see what happens by running a small program which is
int main()
{
while(1)
system(fork());
return 0;
}
The system immediately hung.Can anyone explain why my system hung?
Some systems place no limit and will simply keep appending to a running queue as needed. There are options to restrict the maximum number of processes that a system can use but by default there are no restrictions (on some systems). On Linux you can change the ulimit which is processes per user and if you set it to something like 500 or less you will see that this program will not hang the system and will simply just run and use up CPU cycles from doing constant context switches.
By the way, what you're doing there is called a Fork Bomb and it is a small denial exploit used to cause a denial of service attack on a computer that does not have a limit on processes per user.
Related
In operating system there should be a mechanism to prevent infinite loops. I want to know which steps follow the OS to prevent infinite loops and terminate the process by OS.
Let's start with an (over-simplified) example of an infinite loop:
while(true) {
get_user_input();
handle_user_input();
}
Almost every application you've ever used is (a more complex) infinite loop like this; and it's not just applications (e.g. a web server might loop forever while checking for new connections on a TCP/IP port).
Infinite loops are often necessary, and processes shouldn't be terminated just because they do something that may be necessary.
With this in mind the question becomes: How does an OS detect the difference between an unwanted and unintended infinite loop, and a wanted, intentional and necessary infinite loop?
The answer is that an OS can't.
What an OS can do is have various rules that have nothing to do with infinite loops; like:
a high priority thread may only use 100 milliseconds of CPU time between calling a potentially blocking IO operation (e.g. like reading from a network socket); so that if a high priority thread consumes too much CPU time it can be declared "unresponsive" (regardless of whether it's in an infinite loop or not).
a thread that communicates with the GUI must accept new events (user input, notifications, etc) within 1 second; so that if a thread takes too long to accept an event from GUI it can be declared "unresponsive" (regardless of whether it's in an infinite loop or not).
Of course this kind of thing is OS specific; and there aren't too many rules like this that won't cause problems for correct software.
-I would like to know, if we have a single core cpu and lets say that for a long time there are only cpu intesive processes (no I\O requests) how does the scheduler regain the control?
-I have read some stuff about timer interupts, i would like to know how is, the operating system, able to set this timer?
I would like to know, if we have a single core cpu and lets say that for a long time there are only cpu intesive processes (no I\O requests) how does the scheduler regain the control?
There's multiple choices:
a) It's a cooperative scheduler and gets control when the currently running task voluntarily or accidentally gives the scheduler control via. a kernel API function (which might be like yield() but could be anything that cause the currently running task to block - e.g. read()) or an exception (e.g. trying to access data that the kernel sent to swap space, causing a page fault where the page fault handler blocks the task until the data it needs is fetched from swap space). This can include the task crashing.
b) It's a preemptive scheduler that uses hardware (e.g. a timer) to ensure that kernel will gain control (and pass control to scheduler). Note that it might or might not be a timer (e.g. it could be a counter that counts the number of instructions executed, which has advantages for modern systems where CPU speed varies due to power management).
c) It's a "less cooperative/semi-preemptive" scheduler that opportunistically checks if a task switch should be done any time anything causes the kernel to gain control but doesn't explicitly use any hardware to ensure that kernel will gain control (e.g. so that things that seem unrelated to scheduling, like freeing memory, can cause a task switch).
d) It's a combination of the last 2 options - a preemptive scheduler that uses hardware to ensure that kernel will gain control; that (whenever kernel has control for any reason) opportunistically checks if a task switch can be done a little early to avoid a relatively expensive IRQ that would've occurred soon.
I have read some stuff about timer interupts, i would like to know how is, the operating system, able to set this timer?
"The operating system" is a huge amount of stuff (e.g. includes things like data files for a help system and graphics for icons and ...). Typically there is a kernel which is able to do anything it likes with no restrictions; including accessing timer hardware directly.
The exact details of how a kernel would set a timer depends on which kind of timer it is. Note that there may be different types of timer to choose from (e.g. an 80x86 PC might have a PIT chip, an RTC chip, HPET, and a local APIC timer built into each CPU; where some are configured via. IO ports, some are configured via. memory mapped registers, and one may be configured via. special registers/MSRs built into the CPU; where each type of timer has different frequencies, precision, accuracy, capabilities, etc).
Does each system call create a process?
Are all functions (e.g. interrupts) of programs and operating systems executed in the form of processes?
I feel that such a large number of process control blocks, a large number of process scheduling waste a lot of resources.
Or, the kernel instruction of the system call is regarded as part of the current
process.
The short answer is - not exactly. But we have to agree on what we are going to call a "process". A process is more of an abstract idea, which encapsulates multiple instructions, each sequentially executed.
So let's start from the first question.
Does each system call create a process?
No. Each system call is the product of the currently running process, that tells the OS - "Hey OS, I need you to open this file for me, or read these here bits". In this case, the process is a bag of sequentially executed instructions, some are system calls, some are not.
Then we have.
Are all functions (e.g. interrupts) of programs and operating systems executed in the form of processes?
Well this kind of goes back to the first question. We are not considering that a system call (an operation that tell the OS to do something and works under very strict conditions) is a separate process. We will NOT see that system call execution to have its OWN process id (pid).
Then we have.
I feel that such a large number of process control blocks, a large number of process scheduling waste a lot of resources.
Well, I would say, do not underestimate your OS and the capabilities of your hardware. A modern processor with a modern OS on it, is VERY, VERY fast and more than capable of computing billions of instructions in seconds. We can't really imagine how fast that is. I wouldn't worry for optimizations on such a micro-level.
Okay, but let's dig deeper into this. What is a process exactly?
Informally, a process is a program in execution. The status of the current activity of a process is represented by a value, called the program counter, and the contents of the processor’s registers. The memory layout of a process is typically divided into multiple sections.
These sections include:
Text section.
Data section.
Heap section.
Stack section.
As a process executes, it changes state. The state of a process is defined in part by the current activity of that process. Each process is represented in the OS by a process control block (PCB), as you already mentioned.
So we can see that we treat a process as a very complicated structure that is MORE that just occupying CPU time. It has a state, storage, timing, and so on.
But because you are interested in system calls, then what are they?
For us, system calls provide an interface to the services made available by an OS. They are the way we tell the OS to do things FOR US. We know that systems execute thousands of system calls per second.
No, they don't.
The operating system uses software interrupt to execute the system call operation within the same process.
You can imagine them as a function call but they are executed with kernel privileges.
Recently, I have been reading about Operating Systems, and this bugs me a lot.
How is it really possible for one process to manage other process.
Basically a CPU simply executes instructions, after executing one instruction, then it executes the instruction at address pointed by IP and increments the IP.
Let me elaborate my doubt with an example. Lets say I have an User process (or simply a process) which is being executed by CPU. Lets say, it has 'n' instruction and currently executing 'i'th instruction. IP points to (i+1)th instruction.
So, at this point how can all other OS processes like Scheduler, dispatcher etc... comes into play, Since CPU is already executing another process.
One solution (Just a guess), I could think of is , the use of Interrupts and Interrupt Service Routines.
But its only a guess.
PS: I searched and couldn't find any satisfying answer.
With the help of the hardware, ticks causes the CPU to execute operating system code. This code checks the system state and the time that has elapsed since the beginning of this process execution. At this point, the operating system can decide to schedule a different process. All it has to do is save the current state of the running process with the process that is about to start running. (basically changing the content of the registers and saving the registers state before changing to the new process).
Eventually, the CPU is taken away even if the process doesn't want to yield it.
To address your concern, there are no operating system processes in the way you think... it isn't like there are OS processes in the queue waiting among other processes....
I was going through the following lecture notes on OS :
http://williamstallings.com/Extras/OS-Notes/h2.html
What I could draw is that "A process is a stream of execution ,i.e.basically a sequence of statements and so is a thread .However , the register states of one process are independent of the register states of another process but the register states of another thread can be accessed inside a thread. For every process at least one thread is allotted or dedicated ,when a process is started the OS activities for that process are taken over by the thread ( or a thread)"
What was the rationale behind conceiving the idea of threads ? When the OS is running a particular process why do we need some intermediate like a thread between them ?
"However , the register states of one process are independent of the register states of another process but the register states of another thread can be accessed inside a thread".
Can the above statement be taken as in the code for a process we cannot access the register states of a another process but in a code for a thread we can access the register states of another thread ?
(The above question did have the substitution of process and thread by their definition as codes or sequences of streams )
P.S : The title of the question is a metaphoric one .Please forgive if it misleads in any way . :P Could I take the liberty to broaden up and ask that if
the processor generates a thread for every process what does it write in the code for a thread ?(How does the code for a thread look like ? )
Terminology - for a system with virtual memory, threads share the same virtual memory address space, while each process has it's own address space. Processes can share physical memory by having a portion of that memory shared into their virtual address spaces (but the virtual address for each process may be different even though it is the same physical memory block).
Early (1960's) instances of multi-processing were mainframes that ran multiple processes that usually did not communicate with each other. Most of this activity was for batch oriented jobs, with a stream of jobs to be run, often from a punched card reader, or in more advanced situations, from remote job entry sites, which were other computers with a few peripherals (card readers, tape drives, line printers, ... ) that communicated with the mainframe to run jobs. There were also time sharing applications, similar to servers, except in many cases, relatively dumb terminals were used to communicate with the main frame. By the 1970's, APL/SV (A Programmming Language / Share Variables) was a time sharing application / programming language that could share variables between users.
For multi-process / multi-threaded operating systems, the device drivers operate from a queue of requests (such as a file read or write). Each request to be added to a device driver queue is done similar to a context switch so there won't be conflicts between process or thread requests for I/O. Some peripherals, such as mainframe, SCSI, or ... disk drives also operated from an internal queue, and could process I/O requests out of order to reduce random access overhead.
The basic problem that drove thread was how can an application handle multiple tasks at the same time and do it in a system-independent manner?
In classical eunuchs, a process could only do one thing at a time. If you needed to handle multiple things you kicked off multiple processes.
In the olde RSX and VMS systems (and Windoze under the covers), programmers relied on software interrupts. A process could queue I/O requests to multiple devices and receive a software interrupt when the request completed, thus allowing the application to do multiple things at once.
Another approach to the multiple things at once problem was to use event queues (Windoze, X Windows).
The ADA programming language was the first (and still really the only) mainstream programming language to support threads (tasks) as a system independent way to handle these kinds of problems. DOD compliance mandates drove the creation of threads.
Originally, threads were implemented through libraries ("use threads", "many to one model"). With the rise of multiprocessor systems, there became an increased demand to be able to have threads execute in parallel on different processors. This drove the creates of kernel threads in operating systems. (Many operating systems still do not support kernel threads).