Advanced Operating Systems - PowerPoint PPT Presentation

1 / 59
About This Presentation
Title:

Advanced Operating Systems

Description:

Advanced Operating Systems Lecture 2: Design principles University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Univ. of Tehran – PowerPoint PPT presentation

Number of Views:232
Avg rating:3.0/5.0
Slides: 60
Provided by: Larry437
Category:

less

Transcript and Presenter's Notes

Title: Advanced Operating Systems


1
Advanced Operating Systems
Lecture 2 Design principles
  • University of Tehran
  • Dept. of EE and Computer Engineering
  • By
  • Dr. Nasser Yazdani

2
How to design a system
  • Some general guides.
  • References
  • Hints for Computer System Design, by Butler W.
    Lampson
  • Read The Interaction of Architecture and
    Operation System Design, Thomas E. Anderson, et
    al.
  • Lisp Good News, Bad news, How to Win Big,
    Richard P. Gabriel

3
Outline
  • Introduction
  • Lampson general rules
  • The worse is better
  • Interaction between OS and Architecture.

4
Why this discussion
  • sea of possibilities, unclear about how one
    choice will limit his freedom to make other
    choices, or affect the size and performance of
    the entire system.
  • In system design not try the best way (is there?)
    avoid terrible choices.
  • We, as designer, forgot principles, obvious
    problems. Usually, saying something and acting
    another.
  • Pervious discussion, methods, top-down,
    abstraction, modularity, etc., are there.

5
Main and basic questions?
  • Why it helps in making a good system?
  • with functionality (does it work?),
  • speed (is it fast enough?), or
  • fault-tolerance (does it keep working?).
  • Where in the system design it helps?
  • in ensuring completeness,
  • in choosing interfaces,
  • or in devising implementations.

6
Functionality
  • The most important hints, and the vaguest.
    Obtaining the right functionality that is, with
    getting it to do the things you want it to do.
  • Separates Interface and implementation of some
    abstraction from the clients who use the
    abstraction.
  • Three conflicting requirements on interface
  • should be simple,
  • complete, and
  • admit a sufficiently small and fast
    implementation.

7
Functionality (Simplicity1)
  • Perfection is reached not when there is no longer
    anything to add, but when there is no longer
    anything to take away. (A. Saint-Exupery).
  • Do one thing at a time, and do it well. An
    interface should capture the minimum essentials
    of an abstraction. Dont generalize
    generalizations are generally wrong. Too much its
    implementation gt probably be large, slow and
    complicated.
  • KISS Keep It Simple, Stupid. (Anonymous)
  • If in doubt, leave if out. (Anonymous)
  • Exterminate features. (C. Thacker)
  • Everything should be made as simple as possible,
    but no simpler. (A. Einstein)

8
Functionality (Simplicity2)
  • Services must have a fairly predictable cost, and
    the interface must not promise more than the
    implementer knows how to deliver.
  • PL/1 got into serious trouble by attempting to
    provide consistent meanings for a large number of
    generic operations across a wide variety of data
    types.

9
Functionality (Simplicity3)
  • The Tenex system reports a reference to an
    unassigned virtual page by a trap to the user
    program. One of arguments of CONNECT to obtain
    access to another directory is a string
    containing the password. If the password is
    wrong, the call fails after a three second delay,
    to prevent guessing passwords at high speed.
  • for i 0 to Length(directoryPassword) do
  • if directoryPasswordi ¹ passwordArgumenti
    then
  • Wait three seconds return BadPassword
  • connect to directory return Success
  • The following trick finds a password of length n
    in 64n tries on the average, rather than 128n/2
    Arrange the passwordArgument so that its first
    character is the last character of a page and the
    next page is unassigned, and try each possible
    character as the first. If CONNECT reports
    BadPassword, the guess was wrong if an
    unassigned page, it was correct. Now arrange the
    passwordArgument so that its second character is
    the last character of the page, and proceed in
    the obvious way.

10
Functionality (Simplicity4)
  • An engineer is a man who can do for a dime what
    any fool can do for a dollar. (Anonymous)
  • Get it right. Neither abstraction nor simplicity
    is a substitute for getting it right. In fact,
    abstraction can be a source of severe
    difficulties.
  • for i 0 to numberofFields do
  • FindIthField if its name is name then exit
  • end loop
  • In name contents Takes O(n2) to find name
    field?

11
Functionality (Other consideration 1)
  • Make it fast, rather than general or powerful.
  • RISC 39 doing general instructions like store,
    load, etc., quick can run programs faster than
    machines like the VAX with more general and
    powerful instructions that take longer in the
    simple cases. It is easy to lose a factor of two
    in the running time of a program.
  • To find the places where time is being spent in a
    large system. Need measurement tools that will
    pinpoint the time-consuming code.

12
Functionality (Other consideration 1)
  • Make it fast, Other people opinion
  • Make it simple
  • Beware premature optimization
  • Ousterhout The biggest speedup is when a system
    goes from working to not working. Thats infinite
    speedup.
  • it is necessary to have measurement tools ...
  • Design a system with a structure that
    facilitates incremental tuning

13
Functionality (Other consideration 2)
  • Dont hide power.
  • When a low level of abstraction allows something
    to be done quickly, higher levels should not bury
    this power inside something more general.
  • Alto disk hardware 53 can transfer a full
    cylinder at disk speed, use it wherever possible.
  • Use procedure arguments to provide flexibility in
    an interface. This technique can greatly simplify
    an interface, eliminating unnecessary parameters.

14
Functionality (Other consideration 3)
  • Leave it to the client.
  • An interface can combine simplicity, flexibility
    and high performance by solving only one problem
    and leaving the rest to the client.
  • Success of monitors as a synchronization device
    is partly due to the fact that the locking and
    signaling mechanisms do very little, leaving all
    the real work to the client programs.
  • Unix encourages building small programs taking
    one or more character streams, produce one or
    more streams as output, and do one operation.
    Each program has a simple interface and does one
    thing well, leaving the client to combine a set
    of such programs with its own code.

15
Functionality (Continuity1)
  • Keep basic interfaces stable.
  • An interface embodies assumptions that are shared
    by more than one part of a system or many
    systems. It is very desirable not to change the
    interface.
  • Keep a place to stand if you have to change the
    interface.
  • IBM 360/370 systems provided emulation of the
    instruction sets of older machines.
  • Success of Microsoft due to the compatibility
    with the older version or products. DOS on Windows

16
Functionality ( Making it works)
  • Plan to throw one away you will anyhow
  • It costs a lot less if you plan to have a
    prototype. Rethink about old and new features.
  • Keep secrets of the implementation. Assumptions
    about an implementation that client programs are
    not allowed to make. They are things that can
    change the interface defines the things that
    cannot change.
  • Divide and conquer.
  • Use a good idea again instead of generalizing it.
  • A specialized implementation of the idea may be
    much more effective than a general one.

17
Functionality ( Handling cases)
  • Handle normal and worst cases separately The
    normal case must be fast. The worst case must
    make some progress. In scheduling we might face
    deadlock. Checking safety of status are extremely
    costly. Treat deadlock differently.

18
Speed ( 1)
  • Split resources in a fixed way if in doubt,
    rather than sharing them.
  • It is usually faster to allocate dedicated
    resources, access them, and the behavior of the
    allocator is more predictable.
  • Disadvantage is that more total resources are
    needed, ignoring multiplexing overheads, than if
    all come from a common pool.
  • Ex. Use registers for local variable since they
    fast.
  • Dynamic translation (compact, easily modified or
    easily displayed) representation to one that can
    be quickly interpreted.
  • Smalltalk use byte codes and translate them on
    invoking

19
Speed ( 2)
  • Cache answers to expensive computations, rather
    than doing them over or precomputing. Prefetching
    instructions.
  • Use hints to speed up normal execution. Using
    link or references for allocated/free spaces. Try
    to avoid lengthy searches
  • When in doubt, use brute force. Cost of hardware
    declines, straightforward and easily analyzed
    solution requiring computing cycles is better
    than a complex, poorly characterized one that may
    work well under certain assumptions. Ex. Ken
    Thompsons chess machine, personal computers vs.
    time-sharing systems

20
Speed ( 3)
  • Compute in background when possible. Ex. garbage
    collection algorithm, backups on the middle of
    night.
  • Use batch processing if possible.
  • Safety first. In allocating resources, strive to
    avoid disaster rather than to attain an optimum.
    a general-purpose system cannot optimize the use
    of resources. It is easy enough to overload a
    system and drastically degrade the service if it
    exceeds two-thirds of the capacity. Ex. Page
    prediction algorithm have no use, the memory is
    cheep
  • The nicest thing about the Alto is that it
    doesnt run faster at night. (J. Morris)

21
Speed ( 4)
  • Shed load to control demand, rather than allowing
    the system to become overloaded.
  • An interactive system can refuse new users, or
    even deny service to existing ones. A memory
    manager can limit the jobs being served so that
    all their working sets fit in the available
    memory.
  • Bob Morris suggested that a shared interactive
    system should have a large red button on each
    terminal.
  • Ethernet, IP are best effort delivery.

22
Fault-tolerance( 1)
  • The unavoidable price of reliability is
    simplicity. (C. Hoare)
  • End-to-end. Ex. Error recovery at the reliable
    data transmission.
  • Requires a cheap test for success.
  • Lead to working systems with severe performance
    defects that may not appear until the system
    becomes operational and is placed under heavy
    load.
  • Log updates to record the truth about the state
    of an object.
  • Make actions atomic or restartable.

23
Final word of Lampson
  • Most humbly do I take my leave, my lord.
  • Still we are left with building big and working
    systems.

24
Worse is Better
  • Two style of design
  • MIT/Stanford style Get it right. Ex. Common
    Lisp.
  • ATT style or New Jersey approach Get it work.
    Ex. Early Unix and C

25
MIT/Stanford style
  • Simplicity-the design must be simple, both in
    implementation and interface. Interface is more
    important.
  • Correctness.
  • Consistency-the design must not be inconsistent.
    A design is allowed to be slightly less simple
    and less complete to avoid inconsistency.
    Consistency is as important as correctness.
  • Completeness-the design must cover as many
    important situations as is practical. All
    reasonably expected cases must be covered.
    Simplicity is not allowed to overly reduce
    completeness.

26
New Jersey style
  • Simplicity-the design must be simple, both in
    implementation and interface. It is more
    important for the implementation to be simple
    than the interface. Simplicity is the most
    important consideration in a design.
  • Correctness-the design must be correct. It is
    slightly better to be simple than correct.
  • Consistency-the design must not be overly
    inconsistent. Consistency can be sacrificed for
    simplicity in some cases, but it is better to
    drop those parts of the design that deal with
    less common circumstances than to introduce
    either implementational complexity or
    inconsistency.
  • Completeness-the design must cover as many
    important situations as is practical.
    Completeness can be sacrificed in favor of any
    other quality. In fact, completeness must
    sacrificed whenever implementation simplicity is
    jeopardized. Consistency can be sacrificed to
    achieve completeness if simplicity is retained
    especially worthless is consistency of interface.

27
Which one is better?
  • New Jersey Style has better survival
    characteristics than the-right-thing.
  • The PC loser-ing problem (in calling a routine)
  • MIT philosophy Back out and restore the user
    program PC to the instruction that invoked the
    system routine.
  • New Jersey Style The system routine to always
    finish, but sometimes an error code would be
    returned that signaled that the system routine
    had failed to complete its action. A correct user
    program, then, had to check the error code to
    determine whether to simply try the system
    routine again. The MIT guy did not like this
    solution because it was not the right thing.

28
Which one is better?
  • Unix and C are the ultimate computer viruses.
    Why?
  • easy to write a decent compiler.
  • writing programs that is easy for the compiler to
    interpret.
  • simple structures, easy to port, require few
    machine resources to run.
  • provide about 50--80 of functionality of an
    operating system and programming language.
  • Implementation simplicity has highest priority!
  • Programmer is conditioned to sacrifice some
    safety, convenience, and hassle to get good
    performance and modest resource use.
  • Initial virus has to be basically good. Then, the
    viral spread is assured as long as it is
    portable. Then, there will be pressure to improve
    it, possibly by increasing its functionality
    closer to 90.
  • gain acceptance
  • will condition its users to expect less.
  • will be improved to a point that is almost the
    right thing.
  • Compare Lisp with C.

29
Which one is better?
  • How does the right thing stack up?
  • big complex system scenario'
  • diamond-like jewel'' scenario
  • big complex system'' scenario First, designed.
    Then its implementation designed. Finally, its
    implemented.
  • it has nearly 100 of desired functionality,
    implementation simplicity is not a concern.
  • long time to implement.
  • large and complex.
  • requires complex tools to use properly.
  • The last 20 takes 80 of the effort,
  • the right thing takes a long time to get out,
    and it only runs satisfactorily on the most
    sophisticated hardware

30
Which one is better?
  • The diamond-like jewel'' scenario
  • takes forever to design.
  • but it is quite small at every point along the
    way.
  • To implement it to run fast is either impossible
    or beyond the capabilities of most implementers.
  • The first scenario is classic artificial
    intelligence software.
  • Both scenarios correspond to Common Lisp.
  • Lesson Not go for the right thing first. Get
    half of the right thing available so that it
    spreads like a virus. Once people are hooked on
    it, take the time to improve it to 90 of the
    right thing.
  • Wrong Lesson C is not the right vehicle for AI
    software

31
History of OS Change!
1980 2000 Factor
Speed CPU 1 MIPS 1000 MIPS 1000
Memory 500 ns 2 ns 250
Disk 18 ms 2 ms 9
Modem 300 bits/sec 56 Kbits/sec 200
Capacity Memory 64 Kbytes 128 Mbytes 2000
Disk 1 Mbytes 6 Gbytes 6000
Cost Per MIP 100K lt 1 100000
Other Address bits 8 64 8
Users/machine 10s lt1 .01
32
Interaction of OS Arch.
  • New Trend in Computer Architecture
  • Simple, directly-executed instruction sets.
  • Open Arch., Make implementation visible to higher
    level.
  • Migration of functions from HW to SW
  • Arch. Features are removed unless can be
    justified by cost/performance
  • OS new requirements,
  • Fast local communication,
  • Distributed programming
  • Parallel programming
  • Virtual Memory

33
Interaction of OS Arch.
  • improved extensibility,
  • maintainability,
  • fault tolerance,
  • New system like Mach are moving toward more
    modular organization.
  • Unfortunately, modern OS and Arch. have evolved
    somewhat independently
  • Studies for performance overlook OS. In VAX 50
    of reference are for OS. Application result does
    not apply to OS.
  • Modern Arch. Studies traditional OS not new
    requirement.
  • OS is focused on Performance, until HW limits.
    Then, HW is bottleneck. But still it takes into
    account old Arch.
  • OS might be optimized not Software on top of it.

34
Some tests
  • Compared performance of several modern
    microprocessors based on
  • Null system call time to enter a null C
    procedure in the kernel, with interrupt
    (re-)enabled, and then return.
  • Trap time to take a data access fault (e.g., on
    a protection violation), vector to a null C
    procedure in the kernel, and return. This
    requires saving and restoring any registers that
    are not preserved across procedure calls.
  • Page table entry change the time, once in the
    kernel, to convert a virtual address into its
    corresponding page table entry, update that entry
    to change protection information, and then update
    any hardware (e.g., the translation buffer) that
    caches this information.
  • Context switch

35
Some tests (Cont)
  • Results for a CISC, VAXstation 3200 (11.1 MHz
    CVAX and four RISC Tektronix XD88/01 (2o MHz
    Motorola 88000, DECstation 3100 (16.6 MHz MIPS
    R2000 Kane 87), DECstation 5000/200 (25 MHz
    MIPS R30001 ) and SPARCstation 1 (25 MHz Sun
    SPARC).

36
Some tests (Cont)
  • Objective isolate architectural impact on
    operating system functions. Restructured drivers
    to remove operating system dependencies and
    measure only the operating system independent
    parts. This often reduced the execution times by
    a factor of two. Further optimized (e.g.,
    removing extraneous procedure calls). Handlers
    were almost entirely written in assembler.
  • Result OS performance is not as good as
    application according to the table Why?
  • More microcode for OS Primitives in RISC.

37
Some tests (Cont)
38
Major OS components (IPC)
  • IPC is central to modern operating system
    structure and performance.
  • From monolithic, centralized kernels to a more
    decentralized structure. Independent address
    spaces communicating through messages. Using
    message, instead of shared memory simplifies the
    move to a physically distributed topology or
    distributed computing
  • Modularity, fault tolerance, extensibility of
    design.
  • Small kernel. Faster?
  • Resource sharing

39
IPC Cross-Machine Communication
  • RPC has become the preferred method to
    communicate between address spaces, both on the
    same machine and across a network.
  • Encapsulates message oriented communication in
    procedure call semantics.
  • OS overhead dominates network Latency.

40
IPC Cross-Machine Communication
  • Cross-machine RPC involves communication between
    two remote address spaces, the operating system
    must be involved to transfer control and data
    between the client and server.
  • Tripling CPU speed would reduce SRC RPC latency
    by about 50, on the expectation that the 83 of
    the time not spent on the wire will decrease by a
    factor of3.
  • System calls and traps do not scale well.
  • Large register sets and pipelines, present on
    most modern RISCS, are not likely to benefit
    interrupt processing and thread management
    because of the additional state to examine, save,
    and restore. checksum processing is memory
    intensive and not compute intensive each
    checksum addition is paired with a load (which on
    some

41
IPC Local Communication
  • How effectively the operating system can be
    decomposed, as well as how rapidly clients can
    communicate with other servers.
  • Lightweight remote procedure call (LRPC).
  • For the simplest local calls, LRPC achieves a
    3-fold performance

Each LRPC enter Kernel twice Kernel is bottleneck.
42
IPC Sys call interrupt Handling
  • VAX performs functions in hardware as part of the
    system call and return from exception
    instructions, the time to enter and exit the
    kernel is longer, but the cost once in the kernel
    is much less.
  • SPARC use Register window to improve application,
    but 30 of the null sys. Call is on register
    window processing.

43
IPC Sys call interrupt Handling
  • Motorola 88000 loses much of its performance
    advantage because of the complexity of managing
    its pipelines in software when a trap occurs. The
    88000 includes a large number of registers
    containing pipeline state, and these must be
    examined and manipulated on a trap to check for
    and service any outstanding faults.
  • Low level trap handling code on the R2000 makes
    relatively poor use of load and branch delay
    slots. Nearly 50 of the delay slots in this code
    path are unfilled, accounting for approximately
    13 of the null system call time.

44
IPC Data Copying
  • Data copying is another area in which modern
    processors have not scaled proportionally to
    their integer performance, yet it is an important
    aspect of local and remote communication.
  • arguments may have to be copied as many as 4
    times from client to kernel, from kernel to
    server, from server to kernel, and from kernel to
    client. Various optimizations can be applied, but
    even in LRPC which uses a shared client/server
    buffer, two copies are necessary one to copy
    arguments from the invocation stack on the call,
    and one to copy results on the return.

45
IPC Data Copying
  • Problems Mismatch between memory speed and
    processor speed.
  • On Chip cache? One level, two level? But it is
    relatively small.
  • Data copying for message passing and cache
    interface is there too.

46
Virtual Memory
  • The most basic use of virtual memory is to
    support address spaces larger than the physical
    memory.
  • Enhance the system performance. Ex. Mach uses
    copy on write to speed program startup and
    cross-address space communication
  • transparently support parallel programming across
    networks. Important for an illusion of a shared
    memory multiprocessors.
  • Other supports with virtual memory like
    transaction locking, garbage collection

47
Virtual Memory
  • performance of a virtual memory
  • The ratio of physical to virtual memory size.
  • The size and organization of the TLB
  • The cost of servicing a fault
  • Page replacement algorithm.
  • For OS more important factors
  • Flexibility of the addressing mechanism,
  • The information provided by that mechanism, and
  • The ease of handling faults and changing
    hardware VM addressing state.

48
V. M. (Fault Handling)
  • New Arch. Are not good in exception handling,
    besides
  • Motorola 88000 has 5 internal pipelines,
    including an instruction fetch pipeline, each of
    which must be restarted after a fault. Associated
    with these pipelined execution units are nearly
    30 internal registers. During an exception, many
    of these registers must be read, saved, and
    restored, adding to the complexity and latency of
    fault handling. When a page fault occurs on the
    88000, several instructions may be in the process
    of execution, and instructions following the
    faulting instruction may have already completed.
  • Reduction of the information provided to handle
    faults. Intel i860 provides no information on the
    faulting address in fact, it provides little
    information about why the fault occurred. Trap
    handler knows only that a data access fault of
    some type occurred, and the address of the
    faulting instruction. The fault handler must
    interpret the faulting instruction to determine
    the type of fault and the offending address. This
    requirement adds 26 instructions to our trap
    handler

49
V. M. (TLB and page tables)
  • Formerly, TLB miss handling was hidden from the
    operating system, but some new RISC architectures
    have moved TLB management into software. Adv.
    Flexibility in page table structure.
  • MIPS virtual address space is divided into two
    halves user and system spaces. User space
    addresses are always translated through the TLB.
    System space, however, is again subdivided into
    four regions unmapped and cached, unmapped and
    uncached, mapped and cached, and mapped and
    uncached. Unfortunately, TLB is used poorly by
    OS, in VAX 11/780 two thirds of all TLB misses.
  • Unmapped region is accessed directly through a
    physical base register, there is no indirection
    and therefore no ability to specify page-level
    protection or access control, except to the
    entire region.

50
Threads and Multiproccessing
  • Threads, or lightweight processes, have become
    a common and necessary component of new languages
    and operating systems
  • System level and user level thread.
  • User-level thread systems can provide
    high-performance parallel programming primitives
    that approach minimal hardware costs due to low
    cost of communication within a single address
    space.
  • The importance of threads will continue to
    increase in the future.

51
Arch User-level Threads
  • While fine-grained user-level threads require no
    special architectural support, the architecture
    can have a large impact on thread performance.
  • Most crucial is the amount of state that must be
    managed to context switch from one thread to
    another thread in the same address space.
  • Most of the newer RISC processors, such as the
    Sun SPARC, the MIPS R2000 and the IBM RS6000,
    have more than 64 registers, compared to 16 in
    most earlier 32-bit CISC architectures.

52
Arch User-level Threads
On SPARC of registers to be saved depends on
the number of register windows in use at the
time of the context switch. It shown that with 8
windows, on average three need to be
saved/restored on each context switch. It spend
70 of its time To save and restore windows.
Window pointer is privileged Register, then,
user level context is impossible.
53
Arch User-level Threads
  • Larger register sets can reduce memory accesses.
    Register windows greatly reduce the cost of
    parameter passing and register saving on
    procedure call. The assumption was that procedure
    calls are much more frequent than context
    switches. Since context switching was expensive,
    it was avoided if possible. But for user level
    thread parallelism we can avoid it
  • In Synapse, OO, ratio of procedure call to C. S.
    is 211. But, it spend more time on C.S since it
    is 50 times costly.

54
Arch Kernel-level Threads
  • Kernel-level threads can be problematic due to
    less TLB effectiveness (thread context switches
    between separate address spaces), specially, in
    architectures with small numbers of TLB entries
    and when threads are scheduled independently of
    the address space with which they are associated.
  • MIPS R2000/R3000 has no atomic semaphore this
    hurts performance since threads often are used
    for program structure as well as for parallel
    programming. Then, system have to use trap into
    the kernel or locking. Both are expensive.

55
OS Applications
  • Performance of primitive Os functions has not
    scaled with overall processor performance,
  • Low-level primitives such as trap and context
    switch are frequently used
  • These primitives are becoming more frequently
    used as operating system structure evolves.
  • Applications spellcheck- 1 latex-150
    andrew-local (a script of file system intensive
    programs such as copy, compile and search, run
    using an entirely local file system)
    andrew-remote (the same script run using a remote
    file system) link- vmunix (the final link phase
    of a Mach kernel build) and parthenon (a
    resolution-based theorem prover that rises
    multiple threads)

56
OS Applications
57
OS Applications
  • All applications were run on a MIPS R3000-baaed
    DECstation 5000/200 with 24 megabytes of memory.
    We ran each program three times to smooth out the
    effects of paging and file caching
  • Application were running on Mach OS.

58
OS Appl. (Results)
  1. The most important, operating system primitives
    occur frequently, particularly in a small-kernel
    operating system such as Mach 3.o, and their
    performance has a clear effect on application
  2. Decomposed system will execute more low-level
    system functions than a monolithic system.
  3. The number of kernel-level TLB misses is
    significantly larger for all applications running
    under Mach 3.o than it is under Mach 2.5.
  4. The emulated instruction have significant
    performance due to lack of an atomic Test-and-Set
    instruction. Critical sections execute in kernel
    mode in Mach 2.5 and can simply disable
    interrupts. But in Mach 3.0 the operating
    systems critical sections execute at user-level
    a trap to the kernel is needed to provide mutual
    exclusion.

59
Next Lecture
  • Kernel
  • References
  • "Exokernel An Operating System Architecture for
    Application-Level Resource Management",
  • "The x-Kernel An Architecture for Implementing
    Network Protocols"
  • TinyOS An Operating System for Sensor Networks
Write a Comment
User Comments (0)
About PowerShow.com