Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Operating system
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Types of operating systems== ===Multicomputer operating systems=== With [[multiprocessor]]s multiple CPUs share memory. A [[multicomputer]] or [[cluster computer]] has multiple CPUs, each of which [[distributed memory|has its own memory]]. Multicomputers were developed because large multiprocessors are difficult to engineer and prohibitively expensive;{{sfn|Tanenbaum|Bos|2023|p=557}} they are universal in [[cloud computing]] because of the size of the machine needed.{{sfn|Tanenbaum|Bos|2023|p=558}} The different CPUs often need to send and receive messages to each other;{{sfn|Tanenbaum|Bos|2023|p=565}} to ensure good performance, the operating systems for these machines need to minimize this copying of [[Network packet|packet]]s.{{sfn|Tanenbaum|Bos|2023|p=562}} Newer systems are often [[multiqueue]]—separating groups of users into separate [[Priority queue|queue]]s—to reduce the need for packet copying and support more concurrent users.{{sfn|Tanenbaum|Bos|2023|p=563}} Another technique is [[remote direct memory access]], which enables each CPU to access memory belonging to other CPUs.{{sfn|Tanenbaum|Bos|2023|p=565}} Multicomputer operating systems often support [[remote procedure call]]s where a CPU can call a [[Procedural programming|procedure]] on another CPU,{{sfn|Tanenbaum|Bos|2023|p=569}} or [[distributed shared memory]], in which the operating system uses [[virtualization]] to generate shared memory that does not physically exist.{{sfn|Tanenbaum|Bos|2023|p=571}} ===Distributed systems=== A [[distributed system]] is a group of distinct, [[Computer network|networked]] computers—each of which might have their own operating system and file system. Unlike multicomputers, they may be dispersed anywhere in the world.{{sfn|Tanenbaum|Bos|2023|p=579}} [[Middleware]], an additional software layer between the operating system and applications, is often used to improve consistency. Although it functions similarly to an operating system, it is not a true operating system.{{sfn|Tanenbaum|Bos|2023|p=581}} ===Embedded=== [[Embedded operating system]]s are designed to be used in [[Embedded system|embedded computer systems]], whether they are [[internet of things]] objects or not connected to a network. Embedded systems include many household appliances. The distinguishing factor is that they do not load user-installed software. Consequently, they do not need protection between different applications, enabling simpler designs. Very small operating systems might run in less than 10 [[kilobytes]],{{sfn|Tanenbaum|Bos|2023|pp=37-38}} and the smallest are for [[smart cards]].{{sfn|Tanenbaum|Bos|2023|p=39}} Examples include [[Embedded Linux]], [[QNX]], [[VxWorks]], and the extra-small systems [[RIOT (operating system)|RIOT]] and [[TinyOS]].{{sfn|Tanenbaum|Bos|2023|p=38}} ===Real-time=== A [[real-time operating system]] is an operating system that guarantees to process [[Event (computing)|events]] or data by or at a specific moment in time. Hard real-time systems require exact timing and are common in [[manufacturing]], [[avionics]], military, and other similar uses.{{sfn|Tanenbaum|Bos|2023|p=38}} With soft real-time systems, the occasional missed event is acceptable; this category often includes audio or multimedia systems, as well as smartphones.{{sfn|Tanenbaum|Bos|2023|p=38}} In order for hard real-time systems be sufficiently exact in their timing, often they are just a library with no protection between applications, such as [[eCos]].{{sfn|Tanenbaum|Bos|2023|p=38}} ===Hypervisor=== A [[hypervisor]] is an operating system that runs a [[virtual machine]]. The virtual machine is unaware that it is an application and operates as if it had its own hardware.{{sfn|Anderson|Dahlin|2014|p=11}}{{sfn|Silberschatz et al.|2018|pp=701}} Virtual machines can be paused, saved, and resumed, making them useful for operating systems research, development,{{sfn|Silberschatz et al.|2018|pp=705}} and debugging.{{sfn|Anderson|Dahlin|2014|p=12}} They also enhance portability by enabling applications to be run on a computer even if they are not compatible with the base operating system.{{sfn|Anderson|Dahlin|2014|p=11}} ===Library=== A ''library operating system'' (libOS) is one in which the services that a typical operating system provides, such as networking, are provided in the form of [[Library (computing)|libraries]] and composed with a single application and configuration code to construct a [[unikernel]]: <ref name="Unikernels">{{cite magazine |last1=Madhavapeddy |first1=Anil |last2=Scott |first2=David J |date=November 2013 |title=Unikernels: Rise of the Virtual Library Operating System: What if all the software layers in a virtual appliance were compiled within the same safe, high-level language framework? |magazine=Queue |volume=11 |issue=11 |pages=30–44 |location=New York, NY, USA |publisher=ACM |issn=1542-7730 |url=https://doi.org/10.1145/2557963.2566628 |doi=10.1145/2557963.2566628 |access-date=2024-08-07 }}</ref> a specialized (only the absolute necessary pieces of code are extracted from libraries and bound together <ref name="Unikraft-Build-Process">{{cite web |url=https://unikraft.org/docs/concepts/build-process |access-date=2024-08-08 |title=Build Process - Unikraft |archive-date=2024-04-22 |archive-url=https://web.archive.org/web/20240422183734/https://unikraft.org/docs/concepts/build-process |url-status=live }}</ref>), [[Single address space operating system|single address space]], machine image that can be deployed to cloud or embedded environments. The operating system code and application code are not executed in separated [[Protection ring|protection domains]] (there is only a single application running, at least conceptually, so there is no need to prevent interference between applications) and OS services are accessed via simple library calls (potentially [[Inline expansion|inlining]] them based on compiler thresholds), without the usual overhead of [[context switch]]es, <ref name="rise-of-libOS">{{cite web |url=https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/ |access-date=2024-08-07 |title=Leave your OS at home: the rise of library operating systems |date=2017-09-14 |publisher=[[ACM SIGARCH]] |archive-date=2024-03-01 |archive-url=https://web.archive.org/web/20240301072916/https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/ |url-status=live }}</ref> in a way similarly to embedded and real-time OSes. Note that this overhead is not negligible: to the direct cost of mode switching it's necessary to add the indirect pollution of important processor structures (like [[CPU cache]]s, the [[Instruction pipelining|instruction pipeline]], and so on) which affects both user-mode and kernel-mode performance. <ref name="FlexSC">{{cite conference |url=https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls |title=FlexSC: Flexible System Call Scheduling with Exception-Less System Calls |last1=Soares |first1=Livio Baldini <!-- https://liviosoares.github.io/ --> |last2=Stumm |first2=Michael <!-- https://www.eecg.toronto.edu/~stumm/index.html --> |date=2010-10-04 |conference=OSDI '10, 9th USENIX Symposium on Operating System Design and Implementation |conference-url=https://www.usenix.org/legacy/events/osdi10/ |publisher=[[USENIX]] |access-date=2024-08-09 |quote=Synchronous implementation of system calls negatively impacts the performance of system intensive workloads, both in terms of the ''direct'' costs of mode switching and, more interestingly, in terms of the ''indirect'' pollution of important processor structures which affects both user-mode and kernel-mode performance. A motivating example that quantifies the impact of system call pollution on application performance can be seen in Figure 1. It depicts the user-mode instructions per cycles (kernel cycles and instructions are ignored) of one of the SPEC CPU 2006 benchmarks (Xalan) immediately before and after a <code>pwrite</code> system call. There is a significant drop in instructions per cycle (IPC) due to the system call, and it takes up to 14,000 cycles of execution before the IPC of this application returns to its previous level. As we will show, this performance degradation is mainly due to interference caused by the kernel on key processor structures. |quote-page=2 }}</ref>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)