Operating Systems COT 4600 – Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu, Th 3:00-4:00 PM.

Slides:



Advertisements
Similar presentations
Software Architecture Design Chapter 12 Part of Design Analysis Designing Concurrent, Distributed, and Real-Time Applications with UML Hassan Gomaa (2001)
Advertisements

Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
SWE Introduction to Software Engineering
1  1998 Morgan Kaufmann Publishers Lectures for 2nd Edition Note: these lectures are often supplemented with other materials and also problems from the.
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
1 / 26 CS 425/625 Software Engineering Architectural Design Based on Chapter 11 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8t h Ed.,
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
Slide 1 Instructor: Dr. Hong Jiang Teaching Assistant: Mr. Sheng Zhang Department of Computer Science & Engineering University of Nebraska-Lincoln Classroom:
ECE 232 L1 Intro.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 1 Introduction.
Course Instructor: Aisha Azeem
8/5/2015\course\cpeg323-08F\Topic1.ppt1 Topic I Introduction to Computer Architecture and Organization.
Conceptual Modeling of the Healthcare Ecosystem Eng. Andrei Vasilateanu.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
3- System modelling An architectural model presents an abstract view of the sub-systems making up a system May include major information flows between.
COT 5611 Operating Systems Design Principles Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 1:00-2:00 PM.
An Introduction to Software Architecture
IT253: Computer Organization Lecture 1: Introduction Tonga Institute of Higher Education.
12 Systems Analysis and Design in a Changing World, Fifth Edition.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
1 COMPSCI 110 Operating Systems Who - Introductions How - Policies and Administrative Details Why - Objectives and Expectations What - Our Topic: Operating.
1 ITEC 3010 “Systems Analysis and Design, I” LECTURE 10: Use Case Realizations [Prof. Peter Khaiter]
CS355 Advanced Computer Architecture Fatima Khan Prince Sultan University, College for Women.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
(1) ECE 3056: Architecture, Concurrency and Energy in Computation Lecture Notes by MKP and Sudhakar Yalamanchili Sudhakar Yalamanchili (Some small modifications.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Managing Complexity: Systems Design March 2, 2001.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
COT 5405: Design and Analysis of Algorithms Cliff Zou Spring 2015.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
1 / 26 CS 425/625 Software Engineering Architectural Design Based on Chapter 10 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6 th Ed.,
1 Advanced Operating Systems - Fall 2009 Lecture 2 – January 12, 2009 Dan C. Marinescu Office: HEC 439 B.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Operating Systems COT 4600 – Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: W, F 3:00-4:00 PM.
CS223: Software Engineering Lecture 14: Architectural Patterns.
COT 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
COMPSCI 110 Operating Systems
CompSci 280 S Introduction to Software Development
Software Architecture
IT253: Computer Organization
IS301 – Software Engineering Dept of Computer Information Systems
Software Architecture
Software Engineering Architectural Design Chapter 6 Dr.Doaa Sami
Software Design and Architecture
Part 3 Design What does design mean in different fields?
COP 4600 Operating Systems Fall 2010
Topic I Introduction to Computer Architecture and Organization
COT 5611 Operating Systems Design Principles Spring 2014
COT 5611 Operating Systems Design Principles Spring 2012
COT 4600 Operating Systems Fall 2010
Advanced Operating Systems – Fall 2009
CS 425/625 Software Engineering Architectural Design
CGS 3763 Operating Systems Concepts Spring 2013
CGS 3763 Operating Systems Concepts Spring 2013
COT 5611 Operating Systems Design Principles Spring 2012
COT 4600 Operating Systems Fall 2010
COT 4600 Operating Systems Spring 2011
An Introduction to Software Architecture
COT 5611 Operating Systems Design Principles Spring 2012
COT 5611 Operating Systems Design Principles Spring 2014
Segments Introduction: slides minutes
Software Architecture
Presentation transcript:

Operating Systems COT 4600 – Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu, Th 3:00-4:00 PM

Lecture 1 2 Class organization Class webpage: Textbook: ``Principles of Computer Systems Design; An Introduction'' by Jerome Saltzer and Frans Kaasohoek. Publisher: Morgan Kaufmann, ISBN

Lecture 1 3 The textbook has 6 chapters Systems Elements of Computer System Organization The Design of Naming Schemes Enforcing Modularity with Clients and Services Enforcing Modularity with Virtualization Performance

Lecture 1 4 Class revision We have revised the COT 4600 class for the Fall 2009 semester to give the students a fresh look at basic principles guiding the design and implementation of operating systems. The focus of the class is switched from the discussion on ``how'' operating systems are implemented to the identification of the most important questions the designer of an operating system has to address and ``why'' a solution is better than others.

Lecture 1 5 Class revision (cont’d) Another major departure from the more traditional approach in covering operating systems is the emphasize on performance; several lectures cover computer system performance analysis. We also emphasize the ``big picture'' the relationship of operating systems with other subjects from undergraduate curriculum including: computer architecture, programming languages, algorithms, networking, databases, modeling and performance analysis.

Lecture 1 6 Assignments There are 6 homework assignments and a class project. A homework consists of 3-5 problems at the end of each chapter in the textbook The class project: simulate the operation of a simple kernel for a computer system. It involves multiple phases: Simulate a processor with a minimal instruction set operating in kernel and user mode. Due week 4. Virtualize the memory. Design and implement a paging system and a virtual memory manager. Due week 8. Virtualize the processor. Add a thread management system. Due week 10. Add a virtual communication channel allowing threads to communicate using a bounded buffer and send and receive primitives. Due week 14.

Lecture 1 7 Grading Homework: 15% Project: 35% Midterm: 20% Final: 30%

Lecture 1 8 Today: Systems and Complexity Sources of Complexity Modularity, Abstractions, Layering, Hierarchy Next time Names Complexity of Computer Systems Lecture 1

9 Man-made systems Basic requirements for man-made systems: Functionality Performance Cost All systems are physical  the laws of physics governing the functioning of any system must be well understood. Physical resources are limitted.

Lecture 1 10 Complex systems Large number of components Large number of interconnections Many irregularities Long description For man-made systems: a team of designers, implementers, and maintainers.

Lecture 1 11 Issues faced by the designer of a complex system Emerging Properties Propagation of effects Incommensurate scaling Tradeoffs

Lecture 1 12 Emerging properties A characteristic of complex systems  properties that are not evident in the individual components but show up when the components interact with one another. Example: you have several electronic components which radiate electromagnetic energy; if they are too close to one another their function are affected.

Lecture 1 13 How the nature deals with complexity For biological systems: symmetry, construction of complex biological structures from building blocks. Self-organization  though difficult to define, its intuitive meaning is reflected in the observation made by Alan Turing that ``global order can arise from local interactions'' Scale-free systems. Each component interacts directly only with a small number of other components. Man-made systems to imitate nature!!

Lecture 1 14 Scale-free systems The scale-free organization can be best explained in terms of the network model of the system, a random graph with vertices representing the entities and the links representing the relationships among them. In a scale-free organization, the probability P(m) that a vertex interacts with m other vertices decays as a power law: with d a positive real number, regardless of the type and function of the system, the identity of its constituents, and the relationships between them.

Lecture 1 15 Examples of self-organization The collaborative graph of movie actors where links are present if two actors were ever cast in the same movie; in this case d=2. The power grid of the Western US has some 5,000 vertices representing power generating stations; in this case d=4. The World Wide Web, d=2.1. This means that the probability that m pages point to one page is P(m) = m -2.1 The citation of scientific papers d=3.

Lecture 1 16 Propagation of effects In a complex system: Changes of one component affect many other components. Example, changing the size of the tire of a car. A problem affecting one component propagates to others. For example, the collapse of the housing industry in the Us affected the economy of virtually all countries in the world.

Lecture 1 17 Incommensurate scaling Not all components of a complex system follow the same scaling rules. Examples: The pyramids The tankers The power dissipation increases as (clock rate) 3. If you double the clock rate, then the power dissipation increases by a factor of 8 so you need a heat removal system 8 times more powerful.

Lecture 1 18 Trade-offs Many tradeoffs are involved in the design of any system Examples: a network switch  what should be done in hardware and what should be done in software a hybrid car with a gas and an electric engine  how powerful should the gas engine be a spam filter  where to set the threshold

Lecture 1 19 Systems and the environment System  a set of interconnected components that has a an expected behavior observed at the interface with its environment The environment  a critical component to be considered in the design of any system

Lecture 1 20 Two sources of complexity 1. Cascading and interacting requirements 1.1 When the number of requirements grows then the number of exception grows. 1.2 The principle of escalating complexity:

Lecture 1 21 Two sources of complexity (cont’d) 1.3 Meeting many requirements with a single design  the need for generality. Advice: avoid excessive generality. 1.4 Requirement changes: Example: the electric car produced by Tesla.

Lecture 1 22 Two sources of complexity (cont’d) 2. High performance 2.1 Every system must satisfy performance standards. 2.2 The law of diminishing return  the more one improves one performance metrics the more effort the next improvement will require

Lecture 1 23 Modularity for Coping with Complexity Why does modularity reduce complexity  we can focus on the interaction within one module/component. Example: assume that: B - the # of bugs in a program is proportional with N, the number of statements T- the time to debug a program is proportional with N x B thus it is proportional with N 2 Now we divide the program in K modules each with N/K statements each: The time to debug a module is proportional with (N/K) 2 The time to debug the K modules is K x (N/K) 2 = N 2 /K We have reduced the time by a factor of K. Is that so?

Lecture 1 24 Abstractions for Coping with Complexity Abstraction  separation of the interface from the internals or specification from implementation Example: you do not need to know how the engine of your car works in order to drive the car Why abstractions reduce complexity  because they minimize the interconnections between components. Observations: Best division usually follows natural boundaries. The goal is defeated by unintentional or accidental interconnections among components.

Lecture 1 25 More about abstractions Abstractions are critical for understanding critical phenomena. Think about the abstract model of computation provided by the Turing Machine. Do not be carried away by abstractions. For example, often software designers think about an abstract computer and are not concerned about the physical resources available to them. E.g., the small display of a wireless phone.

Lecture 1 26 More about abstractions (cont’d) The robustness principle  be tolerant of inputs and strict on outputs.

Lecture 1 27 More about abstractions (cont’d) The safety margin principle  Keep track of the safty margin of the cliff or you may fall over edge!!

Lecture 1 28 Layering for Coping with Complexity Layering  building a set of successive functional entities with restricted communication patterns, a layer may only communicate with the layer below it and with the one above it. Examples: networking

Lecture 1 29 Hierarchy for Coping with Complexity Hierarchical structures  construct a large system from a small collection of relatively large subsystems Examples: Corporations An army A computer is a collection of subsystems