{"id":169,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:56:51","modified_gmt":"2020-08-22T20:56:51","slug":"this-is-the-page-title-toplevel-3","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=169","title":{"rendered":"Process Basics"},"content":{"rendered":"\nProcesses<\/title>\n<concept id=\"7\" description=\"A process is the running instance of a program.\" \/>\n<p>\nOne basic concept\nof an <glossary>operating system<\/glossary> is the <glossary>process<\/glossary>. If we think\nof the program as the file\nstored on the hard disk or floppy and the process as that program in memory, we can better\nunderstand the difference between a program and a process. Although these two terms are often\ninterchanged or even misused in “casual” conversation, the difference is very important\nfor issues that we talk about later. Often one refers to an <em>instance<\/em> of that command\nor program.\n<\/p>\n<p>\nA process is more than just a program. Especially in a\n<glossary>multi-user<\/glossary>, <glossary>multi-tasking<\/glossary>\n<glossary>operating system<\/glossary>\nsuch as <glossary>UNIX<\/glossary>,\nthere is much more to consider. Each program has a set of data that it uses to do what it needs.\nOften, this data is not part of the program. For example, if you are using a\ntext editor, the file you are editing is not part of the program on disk, but\nis part of the process in memory. If someone else were to be using the same editor, both of you\nwould be using the same program. However, each of you would have a different process in memory. See\nthe figure below to see how this looks graphically.\n<\/p>\n<question id=\"4\" text=\"When one process starts another, the first typically stays in memory.\" \/>\n<p>\n<a onclick=\"opennew('{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}CURRENT_DIRECTORY{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\/processa.gif',272,560)\" >\n<img decoding=\"async\" src=\"processc.gif\" width=560 height=272 border=0 usemap=\"#process_map\">\n<\/a>\n<map name=\"process_map\">\n<area shape=\"RECT\" coords=\"4,129,113,190\" href=\"popup#processes#Programs are read from the hard disk to become processes \">\n<area shape=\"RECT\" coords=\"161,48,313,81\" href=\"popup#processes#Programs are read from the hard disk to become processes \">\n<area shape=\"RECT\" coords=\"157,102,395,208\" href=\"popup#processes#The program is loaded by the kernel which starts the new processs. Although the same program is read, there are seperate processes each time the program is started.\">\n<area shape=\"RECT\" coords=\"460,191,461,192\" href=\"popup#processes#When the kernel creates a process it writes an entry into the process table for each process.\">\n<area shape=\"RECT\" coords=\"464,2,556,269\" href=\"popup#processes#The process table contains a list of all processes on the system, whether they are running or not.\">\n<\/map>\n<p>\n<icaption>Image – Reading programs from the hard disk to create processes. (<b>interactive<\/b>)<\/icaption>\n<p>\nUnder <glossary>UNIX<\/glossary>,\n many different users can be on the system at the same time. In other words, they have processes\nthat are in memory all at the same time. The system needs to keep track of what user is running what\nprocess, which <glossary>terminal<\/glossary> the process is running on, and what other resources the\nprocess has (such as open files). All of this is part of the process.\n<\/p>\n<question id=\"3\" text=\"The process that starts another one is called the\" \/>\n<p>\nWith the exception of the <command>init<\/command> process (PID 1) every process is the child of another process. Therefore every process with the exception of the init process has a “parent” process. In general, every process has the potential to be the parent of another process. Perhaps the\nprogram is coded in such a way that it will never start another process. However, this is a\nlimitation of that programm and not the operating system.\n<\/p>\n<p>\nWhen you log onto a <glossary>UNIX<\/glossary>\nsystem, you usually get access to a <glossary>command line<\/glossary>\ninterpreter, or <glossary>shell<\/glossary>.\nThis takes your input and runs programs for you. If you are familiar with <glossary>DOS<\/glossary>,\nyou already have used a command line interpreter: the COMMAND.COM program. Under DOS, your shell\ngives you the C:> prompt (or something similar). Under UNIX, the prompt is usually something like\n$, #, or {3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}. This shell is a process and it belongs to you. That is, the in-memory (or in-core) copy\nof the shell program belongs to you.\n<\/p>\n<p>\nIf you were to start up an editor, your file would be loaded and you could edit your file. The\ninteresting thing is that the <glossary>shell<\/glossary> has not gone away. It is still in memory.\nUnlike what operating systems like <glossary>DOS<\/glossary> do with some programs, the shell remains\nin memory. The editor is simply another process that belongs to you. Because it was started by the\nshell, the editor is considered a “child” process of the shell. The shell is <i><em>the<\/i><\/em>\n<i>parent<\/i> process of the editor. (A process has only one parent, but may have many children.)\n<\/p>\n<p>\nAs you continue to edit, you delete words, insert new lines, sort your text\nand write it out occasionally to the disk. During this time, the backup is continuing. Someone\nelse on the system may be adding figures to a spreadsheet, while a fourth person may be inputting\norders into a database. No one seems to notice that there are other people on the system. For them,\nit appears as though the processor is working for them alone.\n<\/p>\n<p>\nAnother example we see in the next figure. When you <glossary>login<\/glossary>,\n you normally have a single process, which is your login <glossary>shell<\/glossary>\n(bash). If you start the <glossary>X<\/glossary>\nWindowing System, your shell starts another process, xinit. At this point, both your shell and\nxinit are running, but the shell is waiting for xinit to complete. Once X starts, you may want a\n<glossary>terminal<\/glossary> in which you can enter commands, so you start <command>xterm<\/command>.\n<p>\n<p>\n<div align=center>\n<img decoding=\"async\" src=\"procs.png\" width=263 height=310 border=0 usemap=\"#procs_map\">\n<\/div>\n<map name=\"procs_map\">\n<area shape=\"RECT\" coords=\"2,1,102,67\" href=\"popup#processes#If started when you login, your bash shell will have a parent process of init.\">\n<area shape=\"RECT\" coords=\"2,77,105,141\" href=\"popup#processes#If you start X-Windows yourself, the xinit process will have your bash shell as its parent.\">\n<area shape=\"RECT\" coords=\"2,162,108,232\" href=\"popup#processes#Once X-Windows starts and you get a terminal sessions, the parent of this session is xinit.\">\n<area shape=\"RECT\" coords=\"156,169,259,231\" href=\"popup#processes#You can start multiple processes, like xclock, all of which will have xinit as its parent.\">\n<area shape=\"RECT\" coords=\"5,243,112,308\" href=\"popup#processes#From the terminal, if you start the ps command, it will have the terminal session as its parent.\">\n<\/map>\n<p>\n<icaption>Image – Relationship between parent and child processes. (<b>interactive<\/b>) <\/icaption>\n<p>\nFrom the xterm, you might then start the <command>ps<\/command> command, to see what other processes are running. In addition, you might have\nsomething like I do, where a clock is automatically started when X starts. At this point, your\nprocess tree might look like the figure above.\n<\/p>\n<p>\nThe nice thing about <glossary>UNIX<\/glossary>\nis that while the <glossary>administrator<\/glossary>\nis backing up the system, you could be continuing to edit your file. This is because UNIX knows how\nto take advantage of the hardware to have more than one process in memory at a time. (Note: It is\nnot a good idea to do a backup with people on the system as data may become inconsistent. This was\nonly used as an illustration.)<\/p>\n<p>\nAs I write this sentence, the <glossary>operating system<\/glossary>\nneeds to know whether the characters I press are part of the text\nor commands I want to pass to the editor. Each key that I press needs to be interpreted. Despite the\nfact that I can clip along at about thirty words per minute, the\nCentral Processing Unit(<glossary>CPU<\/glossary>) is spending approximately 99 percent of its time doing nothing.\n<\/p>\n<p>\nThe reason for this is that for a computer, the time between successive keystrokes is an\neternity. Let’s take my Intel Pentium running at a clock speed of 1.7 GHz as an example. The clock\nspeed of 1.7 GHz means that there are 1.7 billion(!) clock cycles per second. Because the Pentium\ngets close to one instruction per clock cycle, this means that within one second, the\n<glossary>CPU<\/glossary> can get close to executing 1.7 billion instructions! No wonder it is\nspending most of its time idle. (Note: This is an oversimplification of what is going on.)<\/p>\n<p>\nA single computer instruction doesn’t really do much. However, being able to do 1.7 billion\nlittle things in one second allows the <glossary>CPU<\/glossary> to give the user an impression of\nbeing the only one on the system. It is simply switching between the different processes so fast\nthat no one is aware of it.\n<\/p>\n<question id=\"5\" text=\"The length of time a process gets to run is called a\" \/>\n<concept id=\"8\" description=\"Linux switches between processes up to 100 times a second.\" \/>\n<concept id=\"9\" description=\"Linux forces processes to give up the CPU.\" \/>\n<p>\nEach user, that is, each process, gets complete access to the <glossary>CPU<\/glossary>\nfor an\nincredibly short period of time. This period of time (referred to as a\n<em>time slice<\/em>) is typically 1\/100th of a second. That means that at the end of that\n1\/100th of a second, it’s someone else’s turn and the current process is <em>forced<\/em>\nto give up the <glossary>CPU<\/glossary>. (In reality,\nit is much more complicated than this. We’ll get into more details <site id=\"83\">later<\/site>.)\n<\/p>\n<p>\nCompare this to an <glossary>operating system<\/glossary>\nlike older Windows like Windows 95\/98. (not Windows NT and later). The program will hang onto\nthe <glossary>CPU<\/glossary> until it decides to give it up. An ill-behaved program can hold\nonto the <glossary>CPU<\/glossary> forever. This is the cause of a system hanging because\nnothing, not even the <glossary>operating system<\/glossary> itself, can gain control of\nthe <glossary>CPU<\/glossary>. Linux uses the concept of <i>pre-emptive<\/i>\n<glossary>multi-tasking<\/glossary>. Here, the system can pre-empt one process or another, to\nlet another have a turn. Older versions of Windows, use <i>co-operative<\/i> multi-tasking.\nThis means the process must be “cooperative” and give up control of the\n<glossary>CPU<\/glossary>.\n<\/p>\n<question id=\"7\" text=\"A process always runs until it has used up its time slice.\" \/>\n<p>\nDepending on the load of the system (how busy it is), a process may get several time slices per\nsecond. However, after it has run for its <glossary>time slice<\/glossary>,\nthe <glossary>operating system<\/glossary> checks to see if some other process\nneeds a turn. If so, that process gets to run\nfor a time slice and then its someone else’s turn: maybe the first process, maybe a new one.\n<\/p>\n<p>\nAs your process is running, it will be given full use of the <glossary>CPU<\/glossary>\nfor the entire 1\/100th of a second unless one of three things happens. Your process may need to wait\nfor some <glossary>event<\/glossary>. For example, the editor I am using to write this in is\nwaiting for me to type in characters. I said that I type about 30 words per minute, so if we assume\nan average of six letters per word, that’s 180 characters per minute, or three characters per second.\nThat means that on average, a character is pressed once every 1\/3 of a second. Because a\n<glossary>time slice<\/glossary> is 1\/100th of a second, more than 30 processes can have a turn on\nthe <glossary>CPU<\/glossary> between each keystroke! Rather than tying everything up, the program\nwaits until the next key is pressed. It puts itself to sleep until it is awoken by some external\nevent, such as the press of a key. Compare this to a “busy loop” where the process keeps checking\nfor a key being pressed.\n<\/p>\n<p>\nWhen I want to write to the disk to save my file, it may appear that it happens instantaneously,\nbut like the “complete-use-of-the-<glossary>CPU<\/glossary> myth,” this is only appearance. The\nsystem will gather requests to write to or read from the disk and do it in chunks. This is much more\nefficient than satisfying everyone’s request when they ask for it.\n<\/p>\n<question id=\"6\" text=\"Data read from the harddisk is stored in the\" \/>\n<p>\nGathering up requests and accessing the disk all at once has another advantage. Often, the data\nthat was just written is needed again, for example, in a database <glossary>application<\/glossary>.\nIf the system wrote everything to the disk immediately, you would have to perform another read to\nget back that same data. Instead, the system holds that data in a special buffer; in other words, it\n“caches” that data in the <glossary>buffer<\/glossary>. This is called the<em> buffer cache<\/em>.\n<\/p>\n<p>\nIf a file is being written to or read from, the system first checks the\nbuffer <glossary>cache<\/glossary>. If on a read it finds what it’s looking for in the buffer\ncache, it has just saved itself a trip to the disk. Because the buffer\ncache is in memory, it is substantially faster to read from memory than\nfrom the disk. Writes are normally written to the <glossary>buffer<\/glossary>\n<glossary>cache<\/glossary>,\n which is then\nwritten out in larger chunks. If the data being written already exists in the\nbuffer <glossary>cache<\/glossary>,\n it is overwritten. The flow of things might look like this:<\/p>\n<p> <div align=\"center\">\n<a onclick=\"opennew('{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}CURRENT_DIRECTORY{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\/fileacca.gif',357,384)\" >\n<img decoding=\"async\" src=\"fileaccc.gif\" width=164 height=402 border=0 usemap=\"#fileacc_map\">\n<\/a>\n<\/div>\n<map name=\"fileacc_map\">\n<area shape=\"RECT\" coords=\"1,1,127,63\" href=\"popup#file access#To read from and write to files applications must first go through the filesystem drivers.\">\n<area shape=\"RECT\" coords=\"1,68,124,141\" href=\"popup#file access#What filesystem drive is accessed will depend on the filesystem type (that is, how the partition is formatted).\">\n<area shape=\"RECT\" coords=\"1,143,125,219\" href=\"popup#file access#The buffer cache is a special memory area which allows applications to read recently used data without having to access the physical hardware.\">\n<area shape=\"RECT\" coords=\"1,221,126,296\" href=\"popup#file access#The disk device drivers are different depending on the physical hardware.\">\n<area shape=\"RECT\" coords=\"2,300,123,354\" href=\"popup#file access#At the bottom of the stack is the physical hardware. Only the disk device drivers need to know how to talk to the physical hardware.\">\n<\/map>\n<p>\n<icaption>Image – Different layers of file access. (<b>interactive<\/b>)<\/icaption>\n<p>\nWhen your process is running and you make a request to read from the hard disk, you typically\ncannot do anything until you have completed the write to the disk. If you haven’t completed your time slice\nyet, it would be a waste not to let someone else have a turn. That’s exactly what the system does. If\nyou decide you need access to some resource that the system cannot immediately give to you, you are\n“put to sleep” to wait. It is said that you are put to sleep waiting on an\n<glossary>event<\/glossary>, the\nevent being the disk access. This is the second case in which you may not get your full time on the\n<glossary>CPU<\/glossary>.\n<\/p>\n<p>\nThe third way that you might not get your full <glossary>time slice<\/glossary>\nis also the result of an external\nevent. If a device (such as a keyboard, the clock, hard disk, etc.) needs to communicate with the\noperating system, it signals this need through the use of an <glossary>interrupt<\/glossary>.\nWhen an interrupt is generated, the <glossary>CPU<\/glossary>\nitself will stop execution of the process and immediately start executing a\nroutine in the <glossary>operating system<\/glossary>\nto handle interrupts. Once the operating system has satisfied this\ninterrupt, it returns to its regularly scheduled process. (Note: Things are much more complicated\nthan that. The “priority” of both the <glossary>interrupt<\/glossary>\nand process are factors here. We will go into more detail in the\n<tutorial id=119>section on the CPU<\/tutorial>.)\n<\/p>\n<p>\nAs I mentioned earlier, there are certain things that the <glossary>operating system<\/glossary>\nkeeps track of as a process is running. The information the operating system is keeping track of is\nreferred to as the process <em>context<\/em>. This might be the <glossary>terminal<\/glossary> you are\nrunning on or what files you have open. The context even includes the internal state of the\n<glossary>CPU<\/glossary>, that is, what the content of each register is.\n<\/p>\n<p>\nWhat happens when a process’s <glossary>time slice<\/glossary>\nhas run out or for some other reason another process gets to run? If things go right (and they\nusually do), eventually that process gets a turn again. However, to do things right, the process\nmust be allowed to return to the exact place where it left off. Any difference could result in\ndisaster.\n<\/p>\n<p>\nYou may have heard of the classic banking problem concerning deducting from your\n<glossary>account<\/glossary>.\nIf the process returned to a place <em>before<\/em> it made the deduction, you would deduct twice.\nIf the process hadn’t yet made the deduction but started up again at a point after which it would\nhave made the deduction, it appears as though the deduction was made. Good for you, but not so good\nfor the bank. Therefore, everything must be put back the way it was.\n<\/p>\n<p>\nThe processors used by Linux (Intel 80386 and later, as well as the\nDEC Alpha, and SPARC) have built-in capabilities to manage both\nmultiple users and multiple tasks. We will get into the details\nof this in later chapters. For now, just be aware of the fact that the\n<glossary>CPU<\/glossary> <em>assists<\/em> the <glossary>operating system<\/glossary>\nin managing users and processes.\nThis shows how multiple processes might look in memory:<\/p>\n<p>\n<div align=\"center\">\n<a onclick=\"opennew('{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}CURRENT_DIRECTORY{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\/procrama.gif',389,313)\" >\n<img loading=\"lazy\" decoding=\"async\" src=\"procramc.gif\" width=\"313\" height=\"380\" border=\"0\" usemap=\"#procram_map\">\n<\/a>\n<\/div>\n<map name=\"procram_map\" >\n<area shape=\"RECT\" coords=\"85,105,145,161\" href=\"popup#processes in RAM#The process is spread out across multiple locations in physical RAM.\">\n<area shape=\"RECT\" coords=\"120,185,201,286\" href=\"popup#processes in RAM#Processes 2 & 3 share a portion of physical memory.\">\n<area shape=\"RECT\" coords=\"187,115,255,178\" href=\"popup#processes in RAM#Process 3 uses a unique area of memory as well as shares memory with process 2.\">\n<area shape=\"RECT\" coords=\"214,263,273,318\" href=\"popup#processes in RAM#Processes 2 & 5 share a portion of physical memory.\">\n<area shape=\"RECT\" coords=\"220,188,284,251\" href=\"popup#processes in RAM#Process 5 uses a unique area of memory as well as shares memory with process 2.\">\n<area shape=\"RECT\" coords=\"42,213,109,279\" href=\"popup#processes in RAM#Process 5 uses two unique areas of memory as well as shares memory with process 2.\">\n<area shape=\"RECT\" coords=\"84,291,150,346\" href=\"popup#processes in RAM#Process 4 does not share memory with any other process.\">\n<area shape=\"RECT\" coords=\"159,300,210,359\" href=\"popup#processes in RAM#Process 1 uses memory in different physical locations.\">\n<\/map>\n<p>\n<icaption>Image – Processes using differing areas of memory. (<b>interactive<\/b>)<\/icaption>\n<p>\nIn addition to user processes, such as shells, text editors, and\ndatabases, there are system processes running. These are processes that were\nstarted by the system. Several of these deal with managing memory and scheduling\nturns on the <glossary>CPU<\/glossary>.\nOthers deal with delivering mail, printing, and other tasks\nthat we take for granted. In principle, both of these kinds of processes are\nidentical. However, system processes can run at much higher priorities and\ntherefore run more often than user processes.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What character is used to put a command in the background when you start it?\" \/>\n<p>\nTypically a system process of this kind is referred to as a <glossary>daemon<\/glossary>\nprocess or <glossary>background process<\/glossary> because\nthey run behind the scenes (i.e. in the background) without user intervention. It is also possible for a\nuser to put one of his or her processes in the background. This is\ndone by using the ampersand (&) <glossary>metacharacter<\/glossary>\nat the end of the command line. (I’ll talk more about metacharacters in the\n<tutorial id=19>section on shells <\/tutorial>.)\n<\/p>\n<p>\nWhat normally happens when you enter a command is that the <glossary>shell<\/glossary>\nwill wait for that command to finish before it accepts a new command. By putting a\ncommand in the background, the <glossary>shell<\/glossary>\ndoes not wait, but rather is ready\nimmediately for the next command. If you wanted, you could put the next command\nin the background as well.\n<\/p>\n<question id=\"8\" text=\"Processing running in the background still take up system resources.\" \/>\n<concept id=\"10\" description=\"A process running in the 'background' still takes up system resources, like memory.\" \/>\n<p>\nI have talked to customers who have\ncomplained about their systems grinding to a halt after they put dozens of\nprocesses in the background. The misconception is that because they didn’t see\nthe process running, it must not be taking up any resources. (Out of sight, out\nof mind.) The issue here is that even though the process is running in the\nbackground and you can’t see it, it still behaves like any other process.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Processes One basic concept of an operating system is the process. If we think of the program as the file stored on the hard disk or floppy and the process as that program in memory, we can better understand the … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=169\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-169","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=169"}],"version-history":[{"count":3,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/169\/revisions"}],"predecessor-version":[{"id":821,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/169\/revisions\/821"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}