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

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Operating System Structure
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 6:00-7:15 PM.
UNIX Chapter 01 Overview of Operating Systems Mr. Mohammad A. Smirat.
W4118 Operating Systems OS Overview Junfeng Yang.
Chapter 2: Impact of Machine Architectures What is the Relationship Between Programs, Programming Languages, and Computers.
1 CMSC 132: Object-Oriented Programming II Nelson Padua-Perez William Pugh Department of Computer Science University of Maryland, College Park.
Object-oriented design CS 345 September 20,2002. Unavoidable Complexity Many software systems are very complex: –Many developers –Ongoing lifespan –Large.
Software Quality Assurance
Software Process and Product Metrics
1.3 Executing Programs. How is Computer Code Transformed into an Executable? Interpreters Compilers Hybrid systems.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Language Evaluation Criteria
CGS 3863 Operating Systems Spring 2013 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 11:30 AM – 1 PM.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
Computer Architecture ECE 4801 Berk Sunar Erkay Savas.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
HW/SW/FW Allocation – Page 1 of 14CSCI 4717 – Computer Architecture CSCI 4717/5717 Computer Architecture Allocation of Hardware, Software, and Firmware.
Chapter 3: Operating-System Structures System Components Operating System Services System Calls System Programs System Structure Virtual Machines System.
Computer Programming Basics Assistant Professor Jeon, Seokhee Assistant Professor Department of Computer Engineering, Kyung Hee University, Korea.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
Intro to Architecture – Page 1 of 22CSCI 4717 – Computer Architecture CSCI 4717/5717 Computer Architecture Topic: Introduction Reading: Chapter 1.
Computer Architecture and Organization Introduction.
COP 5611 Operating Systems Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 2:00-3:00 PM.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Sogang University Advanced Computing System Chap 1. Computer Architecture Hyuk-Jun Lee, PhD Dept. of Computer Science and Engineering Sogang University.
Digital Design and Computer Architecture Dr. Robert D. Kent LT Ext Lecture 1 Introduction.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 7 OS System Structure.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
School of Computer Science & Information Technology G6DICP Introduction to Computer Programming Milena Radenkovic.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Operating Systems Lecture November 2015© Copyright Virtual University of Pakistan 2 Agenda for Today Review of previous lecture Hardware (I/O, memory,
Chapter 1 Computer Abstractions and Technology. Chapter 1 — Computer Abstractions and Technology — 2 The Computer Revolution Progress in computer technology.
Managing Complexity: Systems Design March 2, 2001.
CS 346 – Chapter 2 OS services –OS user interface –System calls –System programs How to make an OS –Implementation –Structure –Virtual machines Commitment.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Chapter 8 Lecture 1 Software Testing. Program testing Testing is intended to show that a program does what it is intended to do and to discover program.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
Silberschatz, Galvin and Gagne  Operating System Concepts UNIT II Operating System Services.
Operating Systems: Wrap-Up Questions answered in this lecture: What is an Operating System? Why are operating systems so interesting? What techniques can.
 Programming - the process of creating computer programs.
1 Advanced Operating Systems - Fall 2009 Lecture 2 – January 12, 2009 Dan C. Marinescu Office: HEC 439 B.
Lecture 4 Page 1 CS 111 Online Modularity and Virtualization CS 111 On-Line MS Program Operating Systems Peter Reiher.
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: Tu, Th 3:00-4:00 PM.
COT 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
1 Chapter 2: Operating-System Structures Services Interface provided to users & programmers –System calls (programmer access) –User level access to system.
Computer Architecture Organization and Architecture
System Components Operating System Services System Calls.
1.3 Operating system services An operating system provide services to programs and to the users of the program. It provides an environment for the execution.
Types for Programs and Proofs
COMPUTER ORGANIZATION & ASSEMBLY LANGUAGE
COT 5611 Operating Systems Design Principles Spring 2014
COT 5611 Operating Systems Design Principles Spring 2012
Advanced Operating Systems – Fall 2009
COP 4600 Operating Systems Fall 2010
COT 5611 Operating Systems Design Principles Spring 2012
COT 4600 Operating Systems Fall 2010
Chapter 1 Introduction(1.1)
Chapter 2: Operating-System Structures
COT 5611 Operating Systems Design Principles Spring 2012
Computer Architecture
Chapter 2: Operating-System Structures
COT 5611 Operating Systems Design Principles Spring 2014
COT 5611 Operating Systems Design Principles Spring 2014
Presentation transcript:

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

Lecture 12 Last time Computer Systems Today: Names Computer Systems versus Other Systems Coping with Computer System Complexity Next time The project Homework 1 due Thursday, September 3, 2009 Lecture 3

Lecture 13 Names Modularity along with abstraction, layering, and hierarchy allow a designer to cope with complexity; Names and addresses  provide the means to connect modules. A system  a bunch of resources, glued together with names Naming allows the designer to: Delay the implementation of some modules; use dummy ones Replace an implementation with another one. Binding  choosing an implementation for a module Delayed binding; use a place holder.

Lecture 14 Names and fundamental abstractions The fundamental abstractions 1. Storage  mem, disk, data struct, File Systems, disk arrays 2. Interpreters  cpu, programming language e.g. java VM 3. Communication  wire, Ethernet rely on names. Naming: Flat Hierarchical

Lecture 15 Computers a distinct species of complex systems The complexity of computer systems not limited by the laws of physics  distant bounds on composition Digital systems are noise-free. The hardware is controlled by software The rate of change unprecedented The cost of digital hardware has dropped in average 30% per year for the past 35 years

Lecture 16 Analog, digital, and hybrid systems Analog systems: the noise from individual components accumulate and the number of components is limited Digital systems: are noise-free the number of components is not limited regeneration  restoration of digital signal levels static discipline  the range of the analog values a device accepts for each input digital value should be wider than the range of analog output values digital components could fail but big mistakes are easier to detect than small ones!! Hybrid systems  e.g., quantum computers and quantum communication systems

Lecture 17 Computers are controlled by software Composition of hardware limited by laws of physics. Composition of software is not physically constrained; software packages of 10 7 lines of code exist Abstractions hide the implementation beneath module interfaces and allow the creation of complex software modification of the modules Abstractions can be leaky. Example, representation of integers, floating point numbers.

Lecture 18 Exponential growth of computers Unprecedented: when a system is ready to be released it may already be obsolete. when one of the parameters of a system changes by a factor of 2  other components must be drastically altered due to the incommensurate scaling. 10  the systems must be redesigned; E.g.; balance CPU, memory, and I/O bandwidth; does not give pause to developers to learn lessons from existing systems find and correct all errors negatively affects “human engineering”  ability to build reliable and user-friendly systems the legal and social frameworks are not ready

Lecture 19 Coping with complexity of computer systems Modularity, abstraction, layering, and hierarchy are necessary but not sufficient. An additional technique  iteration Iteration Design increasingly more complex functionality in the system Test the system at each stage of the iteration to convince yourself that the design is sound Easier to make changes during the design process

Lecture 110 Iteration – design principles Make it easy to change the simplest version must accommodate all changes required by successive versions do not deviate from the original design rationale think carefully about modularity  it is very hard to change it. Take small steps; rebuild the system every day, to discover design flaws and errors. Ask others to test it. Don’t rush to implementation. Think hard before starting to program. Use feedback judiciously  use alpha and beta versions do not be overconfident from an early success Study failures  understand that complex systems fail for complex reasons.

Lecture 111 Curbing complexity In absence of physical laws curb the complexity by good judgment. Easier said than done because: tempted to add new features than in the previous generation competitors have already incorporated the new features the features seem easy to implement the technology has improved human behavior: arrogance, pride, overconfidence…

Lecture 112 Critical elements of information revolution!

Lecture 113

Lecture 114 The relation between homo sapiens and the computers The feelings of the homo sapiens: Hate Frustration Lack of understanding The Operating System A program to “domesticate” the computer. Transforms a “bare machine” into a “user machine” Controls and facilitates access to computing resources; optimizes the use of resources. The relation went through several stages: Many-to-one One-to-one Many-to-many Peer-to-peer

Lecture 115 Resource sharing and complexity A main function of the OS is resource sharing. Sharing computer resources went through several stages with different levels of complexity: Many-to-one One-to-one Many-to-many Peer-to-peer

Lecture 116

Lecture 117