The document discusses operating system support for middleware, including how middleware relies on operating system functions for processes, threads, communication, and memory management. It also examines different operating system architectures like monolithic kernels and microkernels, and how microkernels implement operating system services through dynamically loaded servers to improve extensibility and modularity. Finally, it analyzes how middleware and operating systems work together to provide distributed services through functions like remote procedure calls while managing performance, security, and other issues.
Chorus - Distributed Operating System [ case study ]Akhil Nadh PC
ChorusOS is a microkernel real-time operating system designed as a message-based computational model. ChorusOS started as the Chorus distributed real-time operating system research project at Institut National de Recherche en Informatique et Automatique (INRIA) in France in 1979. During the 1980s, Chorus was one of two earliest microkernels (the other being Mach) and was developed commercially by Chorus Systèmes. Over time, development effort shifted away from distribution aspects to real-time for embedded systems.
PowerPoint Presentation on Distributed Operating Systems,reasons for opting for distributed systems over centralized systems,types of Distributed Systems,Process Migration and its advantages.
very helpful presentation for students who are dealing with network and operating system have a brief introduction about linux and installation of ubuntu and windows Server.I hope you like it.
Advanced Operating System- IntroductionDebasis Das
Introduction to Advanced Operating systems. Many university courses run advanced/ distributed operating system courses in their 4 year engineering programs. This is based on WBUT CS 704 D course but matches many such courses run by different universities. If you need to downloaad this presentation, please send me an email at ddas15847@gmail.com
Overview - Functions of an Operating System – Design Approaches – Types of Advanced
Operating System - Synchronization Mechanisms – Concept of a Process, Concurrent
Processes – The Critical Section Problem, Other Synchronization Problems – Language
Mechanisms for Synchronization – Axiomatic Verification of Parallel Programs - Process
Deadlocks - Preliminaries – Models of Deadlocks, Resources, System State – Necessary and
Sufficient conditions for a Deadlock – Systems with Single-Unit Requests, Consumable
Resources, Reusable Resources.
Chorus - Distributed Operating System [ case study ]Akhil Nadh PC
ChorusOS is a microkernel real-time operating system designed as a message-based computational model. ChorusOS started as the Chorus distributed real-time operating system research project at Institut National de Recherche en Informatique et Automatique (INRIA) in France in 1979. During the 1980s, Chorus was one of two earliest microkernels (the other being Mach) and was developed commercially by Chorus Systèmes. Over time, development effort shifted away from distribution aspects to real-time for embedded systems.
PowerPoint Presentation on Distributed Operating Systems,reasons for opting for distributed systems over centralized systems,types of Distributed Systems,Process Migration and its advantages.
very helpful presentation for students who are dealing with network and operating system have a brief introduction about linux and installation of ubuntu and windows Server.I hope you like it.
Advanced Operating System- IntroductionDebasis Das
Introduction to Advanced Operating systems. Many university courses run advanced/ distributed operating system courses in their 4 year engineering programs. This is based on WBUT CS 704 D course but matches many such courses run by different universities. If you need to downloaad this presentation, please send me an email at ddas15847@gmail.com
Overview - Functions of an Operating System – Design Approaches – Types of Advanced
Operating System - Synchronization Mechanisms – Concept of a Process, Concurrent
Processes – The Critical Section Problem, Other Synchronization Problems – Language
Mechanisms for Synchronization – Axiomatic Verification of Parallel Programs - Process
Deadlocks - Preliminaries – Models of Deadlocks, Resources, System State – Necessary and
Sufficient conditions for a Deadlock – Systems with Single-Unit Requests, Consumable
Resources, Reusable Resources.
1. • Introduction
• The operating system layer
• Protection
• Communication and invocation
• Operating system architecture
Operating System Support
2. Middleware and the Operating System
What is a distributed OS?
• Presents users (and applications) with an integrated
computing platform that hides the individual computers.
• Has control over all of the nodes (computers) in the network
and allocates their resources to tasks without user
involvement.
• In a distributed OS, the user doesn't know (or care)
where his programs are running.
• Examples:
• Cluster computer systems
• V system, Sprite
3. • No distributed OS in general use
– Users have much invested in their application
software
– Users tend to prefer to have a degree of autonomy
for their machines
• Network OS provides autonomy
• Middleware provides network-transparent access
resource
Combination of middleware and network OS
4. • Introduction
• The operating system layer
• Protection
• Communication and invocation
• Operating system architecture
Operating System Support
5. • Operating System
– Tasks: processing, storage and communication
– Components: kernel, library, user-level services
• Middleware
– runs on a variety of OS-hardware combinations
– remote invocations
• Architecture
The relationship between OS and Middleware
6. System layers
Applications, services
Computer &
Platf orm
Middleware
OS: kernel,
libraries &
servers
network hardware
OS1
Computer &
network hardware
Node 1 Node 2
Processes, threads,
communication, ...
OS2
Processes, threads,
communication, ...
Figure 2.1
Software and hardware service layers in distributed systems
Applications, serv ices
Computer and network hardware
Platf orm
Operating system
Middleware
7. • Encapsulation
– provide a set of operations that meet their clients’ needs
• Protection
– protect resource from illegitimate access
• Concurrent processing
– support clients access resource concurrently
• Invocation mechanism: a means of accessing
an encapsulated resource
– Communication
• Pass operation parameters and results between resource managers
– Scheduling
• Schedule the processing of the invoked operation
Functions that OS should provide for middleware
8. • Process manager
– Handles the creation of and operations upon processes.
• Thread manager
– Thread creation, synchronization and scheduling
• Communication manager
– Communication between threads attached to different
processes on the same computer
• Memory manager
– Management of physical and virtual memory
• Supervisor
– Dispatching of interrupts, system call traps and other
exceptions
– control of memory management unit and hardware caches
– processor and floating point unit register manipulations
The core OS components
9. Positioning Middleware
• Network OS’s are not transparent.
• Distributed OS’s are not independent of
computers.
• Middleware can help.
10. Middleware
• What is middleware?
• What is its function?
• Where is it located?
• Why does it exist?
12. Software and hardware service
layers in distributed systems
Applications, serv ices
Computer and network hardware
Platf orm
Operating system
Middleware
13. Middleware and Openness
• In an open middleware-based distributed system, the protocols used by
each middleware layer should be the same, as well as the interfaces they
offer to applications.
• Why should they be open? Why should they not be open?
1.23
16. Middleware and the Operating System
• Middleware implements abstractions that support network-
wide programming. Examples:
• RPC and RMI (Sun RPC, Corba, Java RMI)
• event distribution and filtering (Corba Event Notification, Elvin)
• resource discovery for mobile and ubiquitous computing
• support for multimedia streaming
• Traditional OS's (e.g. early Unix, Windows 3.0)
– simplify, protect and optimize the use of local resources
• Network OS's (e.g. Mach, modern UNIX, Windows NT)
– do the same but they also support a wide range of communication
standards and enable remote processes to access (some) local resources
(e.g. files).
17. DOS vs. NOS vs. Middleware
Discussion
• What is good/bad about DOS?
– Transparency
– Other issues have reduced success.
– Problems are often socio-technological.
• What is good/bad about NOS?
– Simple.
– Decoupled, easy to add/remove.
– Lack of transparency.
• What is good/bad about middleware?
– Easy to make multiplatform.
– Easy to start something new.
• But this can also be bad.
18. Types of Distributed OSs
System Description Main Goal
DOS
Tightly-coupled operating system for multi-
processors and homogeneous
multicomputers
Hide and manage
hardware
resources
NOS
Loosely-coupled operating system for
heterogeneous multicomputers (LAN and
WAN)
Offer local
services to remote
clients
Middleware
Additional layer atop of NOS implementing
general-purpose services
Provide
distribution
transparency
19. • Introduction
• The operating system layer
• Protection
• Communication and invocation
• Operating system architecture
Operating System Support
20. • Maliciously contrived code
• Benign code
– contains a bug
– have unanticipated behavior
• Example: read and write in File System
– Illegal user vs. access right control
– Access the file pointer variable directly
(setFilePointerRandomly) vs. type-safe language
• Type–safe language, e.g. Java or Modula-3
• Non-type-safe language, e.g. C or C++
Illegitimate access
21. • Kernel
– always runs
– complete access privileges for the physical resources
• Different execution mode
– An address space: a collection of ranges of virtual memory
locations, in each of which a specified combination of
memory access rights applies, e.g.: read only or read-write
– supervisor mode (kernel process) / user mode (user process)
– Interface between kernel and user processes: system call trap
• The price for protection
– switching between different processes take many processor
cycles
– a system call trap is a more expensive operation than a
simple method call
Kernel and Protection
22. The System Clock
system clock frequency
clock period(One full period is also called a clock cycle )
"Hertz" (Hz) meaning one cycle per second
10 MHz : 100 nanoseconds
1GHz: 1 nanoseconds
23. • Introduction
• The operating system layer
• Protection
• Communication and invocation
• Operating system architecture
Operating System Support
24. • Communication primitives
– TCP(UDP) Socket in Unix and Windows
– DoOperation, getRequest, sendReply in Amoeba
– Group communication primitives in V system
• Protocols and openness
– provide standard protocols that enable internetworking
between middleware
– integrate novel low-level protocols without upgrading their
application
– Static stack
• new layer to be integrated permanently as a “driver”
– Dynamic stack
• protocol stack be composed on the fly
• E.g. web browser utilize wide-area wireless link on the road and
faster Ethernet connection in the office
Communication primitives & protocols
25. • Invocation costs
– Different invocations
– The factors that matter
• synchronous/asynchronous, domain transition, communication
across a network, thread scheduling and switching
• Invocation over the network
– Delay: the total RPC call time experienced by a client
– Latency: the fixed overhead of an RPC, measured by null
RPC
– Throughput: the rate of data transfer between computers in a
single RPC
– An example
• Threshold: one extra packet to be sent, might be an extra
acknowledge packet is needed
Invocation performance
26. • The performance of RPC and RMI mechanisms is critical for effective
distributed systems.
– Typical times for 'null procedure call':
– Local procedure call < 1 microseconds
– Remote procedure call ~ 10 milliseconds
– 'network time' (involving about 100 bytes transferred, at 100 megabits/sec.)
accounts for only .01 millisecond; the remaining delays must be in OS and
middleware - latency, not communication time.
• Factors affecting RPC/RMI performance
– marshalling/unmarshalling + operation despatch at the server
– data copying:- application -> kernel space -> communication buffers
– thread scheduling and context switching:- including kernel entry
– protocol processing:- for each protocol layer
– network access delays:- connection setup, network latency
10,000 times slower!
Support for communication and invocation
27. Invocations between address spaces
Control transfer via
trap instruction
User Kernel
Thread
User 1 User 2
Control transfer via
privileged instructions
Thread 1 Thread 2
Protection domain
boundary
(a) System call
(b) R PC/RMI (within one computer)
Kernel
(c) RPC/RMI (between computers)
User 1 User 2
Thread 1 Network Thread 2
Kernel 2Kernel 1
28. Delay of an RPC operation when returned data size varies
1000 2000
RPC delay
Requested data
size (bytes)
Packet
size
0
29. A lightweight remote procedure call
1. Copy args
2. Trap to Kernel
4. Execute procedure
and copy results
Client
User stub
Serv er
Kernel
stub
3. Upcall 5. Return (trap)
A
A stack
30. Times for serialized and concurrent invocations
Client Serv er
execute request
Send
Receiv e
unmarshal
marshal
Receiv e
unmarshal
process results
marshal
Send
process args
marshal
Send
process args
transmission
Receiv e
unmarshal
process results
execute request
Send
Receiv e
unmarshal
marshal
marshal
Send
process args
marshal
Send
process args
execute request
Send
Receiv e
unmarshal
marshal
execute request
Send
Receiv e
unmarshal
marshal
Receiv e
unmarshal
process results
Receiv e
unmarshal
process results
tim e
Client Serv er
Serialised inv ocations Concurrent inv ocations
31. • Memory sharing
– rapid communication between processes in the
same computer
• Choice of protocol
– TCP/UDP
• E.g. Persistent connections: several invocations during
one
– OS’s buffer collect several small messages and
send them together
• Invocation within a computer
– Most cross-address-space invocation take place
within a computer
– LRPC (lightweight RPC)
Improve the performance of RPC
32. • Performance characteristics of the Internet
– High latencies, low bandwidths and high server loads
– Network disconnection and reconnection.
– outweigh any benefits that the OS can provide
• Asynchronous operation
– Concurrent invocations
• E.g., the browser fetches multiple images in a home page by
concurrent GET requests
– Asynchronous invocation: non-blocking call
• E.g., CORBA oneway invocation: maybe semantics, or
collect result by a separate call
Asynchronous operation
33. • Persistent asynchronous invocations
– Designed for disconnected operation
– Try indefinitely to perform the invocation, until it is
known to have succeeded or failed, or until the
application cancels the invocation
– QRPC (Queued RPC)
• Client queues outgoing invocation requests in a stable log
• Server queues invocation results
• The issues to programmers
– How user can continue while the results of
invocations are still not known?
Asynchronous operation … continued
34. • Introduction
• The operating system layer
• Protection
• Communication and invocation
• Operating system architecture
Operating System Support
35. • Monolithic kernel
– Kernel is massive: perform all basic operating system functions, megabytes
of code and data
– Kernel is undifferentiated: coded in a non-modular way
– E.g. Unix
– Pros: efficiency
– Cons: lack of structure
• Microkernel
– Kernel provides only the most basic abstractions: address spaces, threads
and local interprocess communication
– All other system services are provided by servers that are dynamically
loaded
– E.g., VM of IBM 370
– Pros: extensibility, modularity, free of bugs
– Cons: relatively inefficiency
• Hybrid approaches
Monolithic kernels and microkernels
36. Monolithic kernel and Microkernel
Monolithic Kernel Microkernel
Serv er: Dy namically loaded server program:Kernel code and data:
.......
.......
Key:
S4
S1 .......
S1 S2 S3
S2 S3 S4
Middleware
Language
support
subsystem
Language
support
subsystem
OS emulation
subsystem
....
Microkernel
Hardware
The microkernel supports middleware via subsystems