= Process
{disambiguate=computing}
{wiki}
= Operating-system process
{synonym}
An <operating-system process> is an execution instance of a program, with an <address space>, one or more <software threads> carrying <execution contexts>, and <operating system> resources such as <file descriptors>. A program describes instructions; an executable <file> stores a form that can be loaded for execution. Starting the same executable twice can create two <operating-system processes>, each with its own evolving state. A <operating-system process> can be waiting for <input-output> or waiting for a turn on the <CPU>, rather than executing at every instant. https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-intro.pdf[Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, Operating Systems: Three Easy Pieces, chapter 4, sections 4.1, 4.3–4.4: program, process and execution states]{ref}
For example, start the same counter program as <operating-system processes> A and B. In this toy mapping, both use <virtual address> `0x1234` for a counter `x`, but A reads `x = 7` while B reads `x = 42`. The number `0x1234` is interpreted through the current <address space>, so it need not denote the same contents in both <operating-system processes>. Writing A's ordinary private counter does not change B's counter. Compare <virtual memory> for an explicit mapping to different <physical addresses>.
\Image[/process-and-thread-address-spaces.png]
{title=Separate <operating-system processes> can interpret the same <virtual address> differently; <software threads> in one process share an <address space>}
Separate <virtual memory> <address spaces> provide a usual default isolation boundary, not a claim that all <computer memory> is universally private. Deliberately shared mappings let <operating-system processes> communicate through the same stored data. Even logically private contents need not occupy distinct <page frames> at every moment: read-only program code can be shared, and <copy-on-write> can keep a common <memory page> until a write requires a private copy. The distinction is between which accesses and changes are permitted and which physical storage is currently reused. https://pages.cs.wisc.edu/~remzi/OSTEP/vm-complete.pdf[Arpaci-Dusseau and Arpaci-Dusseau, OSTEP chapter 23, section 23.1, Other Neat Tricks: copy-on-write and shared mappings]{ref}https://pubs.opengroup.org/onlinepubs/009695099/functions/shm_open.html[The Open Group, POSIX shared-memory object interface, shm_open: multiple processes can refer to the same shared memory object]{ref}
This abstraction lets independent activities reuse the same executable while keeping their changing state separate. <Process scheduling> distributes <CPU> time; <virtual memory> interprets and protects addresses; <file descriptors> connect an execution to open resources. The useful design is controlled independence with explicit ways to share. Creating <operating-system processes>, maintaining their mappings and performing <context switches> require time and <computer memory>; isolation alone gives no universal performance guarantee.
Back to article page
