Presentation is loading. Please wait.

Presentation is loading. Please wait.

Advanced Operating Systems University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani OS design Lecture 3: OS design Univ. of Tehran1.

Similar presentations


Presentation on theme: "Advanced Operating Systems University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani OS design Lecture 3: OS design Univ. of Tehran1."— Presentation transcript:

1 Advanced Operating Systems University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani OS design Lecture 3: OS design Univ. of Tehran1

2 Advanced Operating Systems How to design an OS Some general guides and experiences. References “Exokernel: An Operating System Architecture for Application Level Resource Management”, Dawson R., Engler M, Frans Kaashoek, et al. “On Micro-Kernel Constructions“, Univ. of Tehran2

3 Advanced Operating Systems Outline New applications/requirements Organizing operating systems Some microkernel examples Object-oriented organizations Spring Organization for multiprocessors Univ. of Tehran3

4 Advanced Operating Systems New vision Two important problems: location and scale. Ubiquitous computing: tiny kernels of functionality Virtual Reality Mobility Intelligent devices distributed computing" make networks appear like disks, memory, or other nonnetworked devices. Univ. of Tehran4

5 Advanced Operating Systems What is the big deal? Performance Border crossings are expensive Change in locality Copying between user and kernel buffers Application requirements differ in terms of resource management Univ. of Tehran5

6 Advanced Operating Systems Operating System Organization What is the best way to design an operating system? Put another way, what are the important software characteristics of an OS? What should be in OS kernel or application or partitioning. Is there a minimal set for kernel? Univ. of Tehran6

7 Advanced Operating Systems Important OS Software Characteristics Correctness and simplicity Power and completeness Performance Extensibility and portability Flexibility Scalability Suitability for distributed and parallel systems Compatibility with existing systems Security and fault tolerance Univ. of Tehran7

8 Common OS Organizations Monolithic Virtual machine Structured design Layered designs Object-Oriented Microkernels Trade off between generality and specialization Advanced Operating SystemsUniv. of Tehran8

9 Monolithic OS Design Build OS as single combined module Hopefully using data abstraction. OS lives in its own, single address space Examples DOS early Unix systems most VFS file systems Advanced Operating SystemsUniv. of Tehran9

10 Pros/Cons of Monolithic OS Organization + Highly adaptable (at first...) + Little planning required + Potentially good performance – Hard to extend and change – Eventually becomes extremely complex – Eventually performance becomes poor – Highly prone to bugs Advanced Operating SystemsUniv. of Tehran10

11 Virtual Machine Organizations A base operating system provides services in a very generic way One or more other operating systems live on top of the base system Using the services it provides To offer different views of system to users Examples - IBM’s VM/370, the Java interpreter Advanced Operating SystemsUniv. of Tehran11

12 Pros/Cons of Virtual Machine Organizations + Allows multiple OS personalities on a single machine + Good OS development environment + Can provide good portability of applications – Significant performance problems – Especially if more than 2 layers – Lacking in flexibility Advanced Operating SystemsUniv. of Tehran12

13 Advanced Operating Systems Old idea VM 370 Virtualization for binary support for legacy apps Why resurgence today? Companies want a share of everybody’s pie IBM zSeries “mainframes” support virtualization for server consolidation Enables billing and performance isolation while hosting several customers Microsoft has announced virtualization plans to allow easy upgrades and hosting Linux! Univ. of Tehran13

14 Layered OS Design Design tiny innermost layer of software Next layer out provides more functionality Using services provided by inner layer Continue adding layers until all functionality required has been provided Examples Multics Fluke layered file systems and comm. protocols Advanced Operating SystemsUniv. of Tehran14

15 Pros/Cons of Layered Organization + More structured and extensible + Easy model and development – Performance: Layer crossing can be expensive – In some cases, unnecessary layers, duplicated functionality. Advanced Operating SystemsUniv. of Tehran15

16 Two layer OS Designs Only two OS layers Kernel OS services Non-kernel OS services Move certain functionality outside kernel file systems, libraries Unlike virtual machines, kernel doesn’t stand alone Examples - Most modern Unix systems Advanced Operating SystemsUniv. of Tehran16

17 Pros/Cons of two layer OS + Many advantages of layering, without disadvantage of too many layers + Easier to demonstrate correctness – Not as general as layering – Offers no organizing principle for other parts of OS, user services – Kernels tend to grow to monoliths Advanced Operating SystemsUniv. of Tehran17

18 Object-Oriented OS Design Design internals of OS as set of privileged objects, using OO methods Sometimes extended into application space Tends to lead to client/server style of computing Examples Mach (internally) Spring (totally) Advanced Operating SystemsUniv. of Tehran18

19 Advanced Operating Systems Object-Oriented Organizations Object-oriented organization is increasingly popular Well suited to OS development, in some ways OSes manage important data structures OSes are modularizable Strong interfaces are good in OSes Univ. of Tehran19

20 Advanced Operating Systems Object-Orientation and Extensibility One of the main advantages of object- oriented programming is extensibility Operating systems increasingly need extensibility So, again, object-oriented techniques are a good match for operating system design Univ. of Tehran20

21 Advanced Operating Systems How object-oriented should an OS be? Many OSes have been built with object- oriented techniques E.g., Mach and Windows NT But most of them leave object orientation at the microkernel boundary No attempt to force object orientation on out-of-kernel modules Univ. of Tehran21

22 Pros/Cons of Object Oriented OS Organization + Offers organizational model for entire system + Easily divides system into pieces + Good hooks for security – Can be a limiting model – Must watch for performance problems Not widely used yet Advanced Operating SystemsUniv. of Tehran22

23 Microkernel OS Design Like kernels, only less number of abstractions exported (threads, address space, communication channel) Try to include only small set of required services in the microkernel Moves even more out of innermost OS part Like parts of VM, IPC, paging, etc. System services (e.g. VM manager) implemented as servers on top High comm overhead between services implemented at user level and microkernel limits extensibility in practice Examples - Mach, Amoeba, Plan 9, Windows NT, Chorus, Spring, etc. Advanced Operating SystemsUniv. of Tehran23

24 Pros/Cons of Microkernel Organization + Those of kernels, plus: + Minimizes code for most important OS services + Offers model for entire system – Microkernels tend to grow into kernels – Requires very careful initial design choices – Serious danger of bad performance Advanced Operating SystemsUniv. of Tehran24

25 Advanced Operating Systems Organizing the Total System In microkernel organizations, much of the OS is outside the microkernel But that doesn’t answer the question of how the system as a whole gets organized How do you fit together the components to build an integrated system? While maintaining all the advantages of the microkernel Univ. of Tehran25

26 Micro-ness is in the eye of the beholder Spin X-kernel Exokernel Mach Spring Amoeba Plan 9 Windows NT Some Important Microkernel Designs Advanced Operating SystemsUniv. of Tehran26

27 Mach Mach didn’t start life as a microkernel Became one in Mach 3.0 Object-oriented internally Doesn’t force OO at higher levels Microkernel focus is on communications facilities Much concern with parallel/distributed systems Advanced Operating SystemsUniv. of Tehran27

28 Mach Model Kernel space User space Software emulation layer 4.3BSD emul. SysV emul. HP/UX emul. other emul. User processes Microkernel Advanced Operating SystemsUniv. of Tehran28

29 What’s In the Mach Microkernel? Tasks & Threads Ports and Port Sets Messages Memory Objects Device Support Multiprocessor/Distributed Support Advanced Operating SystemsUniv. of Tehran29

30 Mach Task Model Process port Bootstrap port Exception port Registered ports Address space Thread Process User space Kernel Advanced Operating SystemsUniv. of Tehran30

31 Mach Ports Basic Mach object reference mechanism Kernel-protected communication channel Tasks communicate by sending messages to ports Threads in receiving tasks pull messages off a queue Ports are location independent Port queues protected by kernel; bounded Advanced Operating SystemsUniv. of Tehran31

32 Advanced Operating Systems Port Rights mechanism by which tasks control who may talk to their ports Kernel prevents messages being set to a port unless the sender has its port rights Port rights also control which single task receives on a port Univ. of Tehran32

33 Advanced Operating Systems Port Sets A group of ports sharing a common message queue A thread can receive messages from a port set Thus servicing multiple ports Messages are tagged with the actual port A port can be a member of at most one port set Univ. of Tehran33

34 Mach Messages Typed collection of data objects Unlimited size Sent to particular port May contain actual data or pointer to data Port rights may be passed in a message Kernel inspects messages for particular data types (like port rights) Advanced Operating SystemsUniv. of Tehran34

35 Mach Memory Objects A source of memory accessible by tasks May be managed by user-mode external memory manager a file managed by a file server Accessed by messages through a port Kernel manages physical memory as cache of contents of memory objects Advanced Operating SystemsUniv. of Tehran35

36 Mach Device Support Devices represented by ports Messages control the device and its data transfer Actual device driver outside the kernel in an external object Advanced Operating SystemsUniv. of Tehran36

37 Mach Multiprocessor and DS Support Messages and ports can extend across processor/machine boundaries Location transparent entities Kernel manages distributed hardware Per-processor data structures, but also structures shared across the processors Intermachine messages handled by a server that knows about network details Advanced Operating SystemsUniv. of Tehran37

38 Advanced Operating Systems Mach’s NetMsgServer User-level capability-based networking daemon Handles naming and transport for messages Provides world-wide name service for ports Messages sent to off-node ports go through this server Univ. of Tehran38

39 Advanced Operating Systems NetMsgServer in Action User space Kernel space Sender User process NetMsgServer User space Kernel space Receiver User process NetMsgServer Univ. of Tehran39

40 Mach and User Interfaces Mach was built for the UNIX community UNIX programs don’t know about ports, messages, threads, and tasks How do UNIX programs run under Mach? Mach typically runs a user-level server that offers UNIX emulation Either provides UNIX system call semantics internally or translates it to Mach primitives Advanced Operating SystemsUniv. of Tehran40

41 Windows NT More layered than some microkernel designs NT Microkernel provides base services Executive builds on base services via modules to provide user-level services User-level services used by privileged subsystems (parts of OS) true user programs Advanced Operating SystemsUniv. of Tehran41

42 Windows NT Diagram Hardware Microkernel Executive User Processes Protected Subsystems User Mode Kernel Mode Win32POSIX Advanced Operating SystemsUniv. of Tehran42

43 NT Microkernel Thread scheduling Process switching Exception and interrupt handling Multiprocessor synchronization Only NT part not preemptible or pageable All other NT components runs in threads Advanced Operating SystemsUniv. of Tehran43

44 NT Executive Higher level services than microkernel Runs in kernel mode but separate from the microkernel itself ease of change and expansion Built of independent modules all preemptible and pageable Advanced Operating SystemsUniv. of Tehran44

45 NT Executive Modules Object manager Security reference monitor Process manager Local procedure call facility (a la RPC) Virtual memory manager I/O manager Advanced Operating SystemsUniv. of Tehran45

46 Typical Activity in NT Hardware Kernel Executive Client Process Win32 Protected Subsystem Advanced Operating SystemsUniv. of Tehran46

47 More On Microkernels Microkernels were the research architecture of the 80s But few commercial systems of the 90s really use microkernels To some extent, “microkernel” is now a dirty word in OS design Why? Advanced Operating SystemsUniv. of Tehran47

48 Main Issue What should be in the Kernel? Different designs give different answers. How to implement the system efficiently? Some people think Micro kernel is slow Micro kernel construction paper argue other way. Advanced Operating SystemsUniv. of Tehran48

49 Advanced Operating Systems Exokernel FIXED Hardware Apache InterfaceAbstractions SQL Server Traditional OS Traditional operating systems fix the interface and implementation of OS abstractions. Abstractions must be overly general to work with diverse application needs. Univ. of Tehran49

50 Advanced Operating Systems The Issues Performance Denies applications the advantages of domain- specific optimizations Flexibility Restricts the flexibility of application builders Difficult or impossible to implement own resource management abstractions. Functionality Discourages changes to the implementations of existing abstractions since it is used by different applications Univ. of Tehran50

51 Advanced Operating Systems Performance Example: A DB can have predictable data access patterns, that doesn't fit with OS LRU page replacement, causing bad performance. Cao et al. Found that application-controlled file caching can reduce running time by as much as 45%. There is no single way to abstract physical resources or to implement an abstraction that is best for all applications. OS is forced to make trade-offs Performance improvements of application-specific policies could be substantial Univ. of Tehran51

52 Advanced Operating Systems The Solution Separate protection from management Allow user level to manage resources Application libraries implement OS abstractions Exokernel exports resources Low level interface Protects, does not manage Expose hardware Univ. of Tehran52

53 Advanced Operating Systems Applications know better than Operating Systems what the goal of their resource management decisions should be Applications should be given as much control as possible over those decisions Implementation view Exokernel Philosophy Frame Buffer | TLB | Network | Memory | Disk Exokernel HW Univ. of Tehran53

54 Advanced Operating Systems Example Hardware Exokernel – Application level resource management SQL Server Library OS Customized for SQLServer InterfaceAbstractions Library OS Chosen from available Apache InterfaceAbstractions Exokernel Univ. of Tehran54

55 Advanced Operating Systems Library O.S., which uses the low-level exokernel interface to implement higher-level abstractions. Implementation Overview Frame Buffer | TLB | Network | Memory | Disk Exokernel HW Library O.S. Univ. of Tehran55

56 Advanced Operating Systems Applications link to library kernel, leveraging their higher-level abstractions. Implementation Overview Frame Buffer | TLB | Network | Memory | Disk Exokernel HW Library O.S. Application Library O.S. Application Univ. of Tehran56

57 Advanced Operating Systems End-to-End Argument “if something has to be done by the user program itself, it is wasteful to do it in a lower level as well.” Why should the OS do anything that the user program can do itself? In other words - all an OS should do is securely allocate resources. Univ. of Tehran57

58 Advanced Operating Systems Exokernel design Univ. of Tehran58

59 Advanced Operating Systems Exokernel tasks Track ownership Guard all resources through bind points Revoke access to resources Abort Univ. of Tehran59

60 Advanced Operating Systems Design principle Expose hardware (securely) Expose allocation Expose names Expose revocation Univ. of Tehran60

61 Advanced Operating Systems Secure binding Decouples authorization from use Allows kernel to protect resource without understanding their semantics Example: TLB entry Virtual to physical mapping performed in the library (above exokernel) Binding loaded into the kernel; used multiple times Example: packet filter Predicates loaded into the kernel Checked on each packet arrival Univ. of Tehran61

62 Advanced Operating Systems Implementing secure bindings Hardware mechanisms Capability for physical pages of a file Frame buffer regions (SGI) Software caching Exokernel large software TLB overlaying the hardware TLB Downloading code into kernel Avoid expensive boundary crossings Univ. of Tehran62

63 Advanced Operating Systems Examples of secure binding Physical memory allocation (hardware supported binding) Library allocates physical page Exokernel records the allocator and the permissions and returns a “capability” – an encrypted cypher Every access to this page by the library requires this capability Page fault: Kernel fields it Kicks it up to the library Library allocated a page – gets an encrypted capability Library calls the kernel to enter a particular translation into the TLB by presenting the capability Univ. of Tehran63

64 Advanced Operating Systems Download code into kernel to establish secure binding Packet filter for demultiplexing network packets How to ensure authenticity? Only trusted servers (library OS) can download code into the kernel Other use of downloaded code Execute code on behalf of an app that is not currently scheduled E.g. application handler for garbage collection could be installed in the kernel Univ. of Tehran64

65 Advanced Operating Systems Visible resource revocation Most resources are visibly revoked E.g. processor; physical page Library can then perform necessary action before relinquishing the resource E.g. needed state saving for a processor E.g. update of page table Univ. of Tehran65

66 Advanced Operating Systems Abort protocol Repossession exception passed to the library OS Repossession vector Gives info to the library OS as to what was repossessed so that corrective action can be taken Library OS can seed the vector to enable exokernel to autosave (e.g. disk blocks to which a physical page being repossessed should be written to) Univ. of Tehran66

67 Advanced Operating Systems Aegis – an exokernel Univ. of Tehran67

68 Advanced Operating Systems Secure Bindings Secure Binding – a protection mechanism that decouples authorization from actual use of a resource Allows the kernel to protect resources without having to understand them Univ. of Tehran68

69 Advanced Operating Systems Aegis – processor time slice Linear vector of time slots Round robin An application can mark its “position” in the vector for scheduling Timer interrupt Beginning and end of time slices Control transferred to library specified handler for actual saving/restoring Time to save/restore is bounded Penalty? loss of a time slice next time! Univ. of Tehran69

70 Advanced Operating Systems Aegis – processor environments Exception context Program generated Interrupt context External: e,g. timer Protected entry context Cross domain calls Addressing context Guaranteed mappings implemented by software TLB mimicking the library OS page table Univ. of Tehran70

71 Advanced Operating Systems Aegis performance Univ. of Tehran71 pointer Arithmetic Protected page

72 Advanced Operating Systems Aegis - Address translation On TLB miss Kernel installs hardware from software TLB for guaranteed mappings Otherwise application handler called Application establishes mapping TLB entry with associated capability presented to the kernel Kernel installs and resumes execution of the application Univ. of Tehran72

73 Advanced Operating Systems ExOS – library OS IPC abstraction VM Remote communication using ASH (application specific safe handlers) using message. Takeaway: significant performance improvement possible compared to a monolithic implementation Univ. of Tehran73

74 Advanced Operating Systems Library operating systems Use the low level exokernel interface Higher level abstractions Special purpose implementations An application can choose the library which best suits its needs, or even build its own. Univ. of Tehran74

75 Advanced Operating Systems Exokernel vs. Microkernel A micro-kernel provides abstractions to the hardware such as files, sockets, graphics etc. An exokernel provides almost raw access to the hardware. Univ. of Tehran75

76 Advanced Operating Systems Design Challenge How can an Exokernel allow libOSes to freely manage physical resources while protecting them from each other? Track ownership of resources Secure bindings – libOS can securely bind to machine resources Guard all resource usage Revoke access to resources Univ. of Tehran76

77 Advanced Operating Systems Secure Bindings Exokernel allows libOSes to bind resources using secure bindings Multiplex resources securely Protection for mutually distrusted apps Efficient Univ. of Tehran77

78 Advanced Operating Systems Conclusion An Exokernel securely multiplexes available hardware raw hardware among applications Application level library operating systems implement higher-level traditional OS abstractions LibOSes can specialize an implementation to suit a particular application Univ. of Tehran78

79 Advanced Operating Systems Conclusion The lower the level of a primitive… …the more efficiently it can be implemented … the more latitude it gives to higher level abstractions So, separate management from protection and… …implement protection at a low level (exokernel) … implement management at a higher level (libOS) Univ. of Tehran79

80 Microkernel Construction Most Microkernels do not perform well Is it inherent in the approach or Implementation? IPC, microkernel bottleneck, can implemented an order of magnitude faster. Not supervise memory Minimal address space management, grant, map, flush. Fast kernel-User Switch, usually us but 3 in L3 implementation Advanced Operating SystemsUniv. of Tehran80

81 Advanced Operating Systems Micro Kernel construction Microkernel should provide minimal abstractions Address space, threads, IPC Abstractions machine independent but implementation hardware dependent for performance Myths about inefficiency of micro-kernel stem from inefficient implementation and NOT from microkernel approach Univ. of Tehran81

82 Advanced Operating Systems What abstractions? Determining criterion: Functionality not performance Hardware and microkernel should be trusted but applications are not Hardware provides page-based virtual memory Kernel builds on this to provide protection for services above and outside the microkernel Principles of independence and integrity Subsystems independent of one another Integrity of channels between subsystems protected from other subsystems Univ. of Tehran82

83 Advanced Operating Systems Microkernel Concepts Hardware provides address space mapping from virtual page to a physical page implemented by page tables and TLB Microkernel concept of address spaces Hides the hardware address spaces and provides an abstraction that supports Grant? Map? Flush? These primitives allows building a hierarchy of protected address spaces Univ. of Tehran83

84 Advanced Operating Systems Address spaces A1, P1V1, R map A2, P2V2, R R (P1, v1) R (P2, v2) grant A2, P2V2, NIL R (P1, v1) (P2, v2) A3, P3V3, R (P3, v3) flush A3, P3V3, NIL R (P1, v1) Univ. of Tehran84 Mem. Manger, process Page table Phy. Mem

85 Advanced Operating Systems Power and flexibility of address spaces Initial memory manager for address space A0 appears by magic (outside the kernel) and encompasses the physical memory Allow creation of stackable memory managers (all outside the kernel) Pagers can be part of a memory manager or outside the memory manager All address space changes (map, grant, flush) orchestrated via kernel for protection Device driver can be implemented as a special memory manager outside the kernel as well Univ. of Tehran85

86 Advanced Operating Systems Microkernel processor M0, A0, P0 PT M1, A1, P1 PT M2, A2, P2 PT Map/grant Univ. of Tehran86

87 Advanced Operating Systems Threads and IPC Executes in an address space PC, SP, processor registers, and state info (such as address space) IPC is cross address space communication Supported by the microkernel Classic method is message passing between threads via the kernel Sender sends info; receiver decides if it wants to receive it, and if so where Address space operations such as map, grant, flush need IPC Higher level communication (e.g. RPC) built on top of basic IPC Univ. of Tehran87

88 Advanced Operating Systems Interrupts? Each hardware device is a thread from kernel’s perspective Interrupt is a null message from a hardware thread to the software thread Kernel transforms hardware interrupt into a message Does not know or care about the semantics of the interrupt Device specific interrupt handling outside the kernel Clearing hardware state (if privileged) then carried out by the kernel upon driver thread’s next IPC TLB handler? In theory software TLB handler can be outside the microkernel In practice first level TLB handler inside the microkernel or in hardware Univ. of Tehran88

89 Advanced Operating Systems Unique IDs Kernel provides uid over space and time for Threads IPC channels Univ. of Tehran89

90 Advanced Operating Systems Breaking some performance myths Kernel user switches Address space switches Thread switches and IPC Memory effects Base system: 486 (50 MHz) – 20 ns cycle time Univ. of Tehran90

91 Advanced Operating Systems Kernel-user switches Machine instruction for entering and exiting 107 cycles Mach measures 900 cycles for kernel-user switch Why? Empirical proof L3 kernel ~ 123 cycles (accounting for some TLB, cache misses) Where did the remaining 800 cycles go in MACH? Kernel overhead (construction of the kernel, and inherent in the approach) Univ. of Tehran91

92 Advanced Operating Systems Address space switches Primer on TLBs AS tagged TLB (MIPS R4000) vs untagged TLB (486) Untagged TLB requires flush on AS switch Instruction and data caches Usually physically tagged in most modern processors so TLB flush has no effect Address space switch Complete reload of Pentium TLB ~ 864 cycles Univ. of Tehran92

93 Advanced Operating Systems Do we need a TLB flush always? Implementation issue of “protection domains” SPIN implements protection domains as Modula names within a single hardware address space Liedtke suggests similar approach in the microkernel in an architecture-specific manner PowerPC: use segment registers => no flush Pentium or 486: share the linear hardware address space among several user address spaces => no flush There are some caveats in terms of size of user space and how many can be “packed” in a 2**32 global space Univ. of Tehran93

94 Advanced Operating Systems Upshot? Address space switching among medium or small protection domains can ALWAYS be made efficient by careful construction of the microkernel Large address spaces switches are going to be expensive ALWAYS due to cache effects and TLB effects, so switching cost is not the most critical issue Univ. of Tehran94

95 Advanced Operating Systems Thread switches and IPC Univ. of Tehran95

96 Advanced Operating Systems Segment switch (instead of AS switch) makes cross domain calls cheap Univ. of Tehran96

97 Advanced Operating Systems Memory Effects – System Univ. of Tehran97

98 Advanced Operating Systems Capacity induced MCPI Univ. of Tehran98

99 Advanced Operating Systems Portability Vs. Performance Microkernel on top of abstract hardware while portable Cannot exploit hardware features Cannot take precautions to avoid performance problems specific to an arch Incurs performance penalty due to abstract layer Univ. of Tehran99

100 Advanced Operating Systems Examples of non- portability Same processor family Use address space switch implementation TLB flush method preferable for 486 Segment register switch preferable for Pentium => 50% change of microkernel! IPC implementation Details of the cache layout (associativity) requires different handling of IPC buffers in 486 and Pentium Incompatible processors Exokernel on R4000 (tagged TLB) Vs. 486 (untagged TLB) => Microkernels are inherently non-portable Univ. of Tehran100

101 Advanced Operating Systems Summary Minimal set of abstractions in microkernel Microkernels are processor specific (at least in implementation) and non-portable Right abstractions and processor-specific implementation leads to efficient processor-independent abstractions at higher layers Univ. of Tehran101

102 Advanced Operating Systems Next Lecture Process and Thread “Cooperative Task Management Without Manual Stack Management”, by Atul Adya, et.al. “Capriccio: Scalable Threads for Internet Services”, by Ron Von Behrn, et. al. “The Performance Implication of Thread Management Alternative for Shared-Memory Multiprocessors”, Thomas E. Anderson, et.al. Univ. of Tehran102


Download ppt "Advanced Operating Systems University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani OS design Lecture 3: OS design Univ. of Tehran1."

Similar presentations


Ads by Google