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

Slides:



Advertisements
Similar presentations
Categories of I/O Devices
Advertisements

SLC/Ver1.0/OS CONCEPTS/Oct'991INTRODUCTION What is an Operating System? Operating Structure -System Components -OS Services -System Calls & Programs -System.
Operating System Structure
Operating-System Structures
Layer 7- Application Layer
1 CS 333 Introduction to Operating Systems Class 2 – OS-Related Hardware & Software The Process Concept Jonathan Walpole Computer Science Portland State.
CSCI 4550/8556 Computer Networks Comer, Chapter 19: Binding Protocol Addresses (ARP)
Cs238 Lecture 3 Operating System Structures Dr. Alan R. Davis.
Chapter 2: Impact of Machine Architectures What is the Relationship Between Programs, Programming Languages, and Computers.
NFS. The Sun Network File System (NFS) An implementation and a specification of a software system for accessing remote files across LANs. The implementation.
Linux Operations and Administration
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
Chapter 3.1:Operating Systems Concepts 1. A Computer Model An operating system has to deal with the fact that a computer is made up of a CPU, random access.
COT 5611 Operating Systems Design Principles Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 1:00-2:00 PM.
System Calls 1.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
Chapter 1: Introduction to Web Applications. This chapter gives an overview of the Internet, and where the World Wide Web fits in. It then outlines the.
5 Chapter Five Web Servers. 5 Chapter Objectives Learn about the Microsoft Personal Web Server Software Learn how to improve Web site performance Learn.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Networks – Network Architecture Network architecture is specification of design principles (including data formats and procedures) for creating a network.
Contact Information Office: 225 Neville Hall Office Hours: Monday and Wednesday 12:00-1:00 and by appointment.
COP 5611 Operating Systems Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 2:00-3:00 PM.
1 Version 3.0 Module 11 TCP Application and Transport.
TCP/IP Protocol Suite 1 Chapter 17 Upon completion you will be able to: Domain Name System: DNS Understand how the DNS is organized Know the domains in.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Chapter 34 Java Technology for Active Web Documents methods used to provide continuous Web updates to browser – Server push – Active documents.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 3: Operating-System Structures System Components Operating System Services.
The Inter-network is a big network of networks.. The five-layer networking model for the internet.
Computer Architecture Lecture 2 System Buses. Program Concept Hardwired systems are inflexible General purpose hardware can do different tasks, given.
Processes Introduction to Operating Systems: Module 3.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
Hwajung Lee.  Interprocess Communication (IPC) is at the heart of distributed computing.  Processes and Threads  Process is the execution of a program.
ECEG-3202 Computer Architecture and Organization Chapter 3 Top Level View of Computer Function and Interconnection.
1 Web Servers (Chapter 21 – Pages( ) Outline 21.1 Introduction 21.2 HTTP Request Types 21.3 System Architecture.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
Mapping IP Addresses to Hardware Addresses Chapter 5.
4 Linking the Components Linking The Components A computer is a system with data and instructions flowing between its components in response to processor.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:00-4:00 PM.
COP 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM.
Major OS Components CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
COT 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM.
Hello world !!! ASCII representation of hello.c.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
Operating Systems A Biswas, Dept. of Information Technology.
CSCI/CMPE 4334 Operating Systems Review: Exam 1 1.
1 Chapter 2: Operating-System Structures Services Interface provided to users & programmers –System calls (programmer access) –User level access to system.
COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
Introduction to Operating Systems Concepts
Chapter 2: System Structures
Lecture 1 Runtime environments.
Subject Name: Computer Communication Networks Subject Code: 10EC71
COP 4600 Operating Systems Fall 2010
COT 4600 Operating Systems Fall 2010
COP 4600 Operating Systems Spring 2011
Chapter 2: System Structures
COT 5611 Operating Systems Design Principles Spring 2014
CGS 3763 Operating Systems Concepts Spring 2013
COT 4600 Operating Systems Fall 2010
COT 5611 Operating Systems Design Principles Spring 2010
Outline Operating System Organization Operating System Examples
COT 5611 Operating Systems Design Principles Spring 2014
Exceptions and networking
Presentation transcript:

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

Lecture 6 22 Lecture 5 Lecture 6 Last time:  Names and the basic abstractions  1. Storage Today:  2. Interpreters  3. Communication Links  Internet or what is behind the abstractions… Next Time  Naming in computing systems

Lecture 6 3 Interpreters The active elements of a computer system Diverse  Hardware  Processor, Disk Controller, Display controller  Software  script language: Javascropt, Pearl, Python text processing systems: Latex, Tex, Word browser : Safari, Google Chrome,Thunderbird All share three major abstractions/components:  Instruction reference  tells the system where to find the next instruction  Repertoire  the set of actions (instructions) the interpreter is able to perform  Environment reference  tells the interpreter where to find the its environment, the state in which it should be to execute the next instruction 3

Lecture 6 4 An abstract interpreter The three elements allow us to describe the functioning of an interpreter regardless of its physical realization. Interrupt  mechanism allowing an interpreter to deal with the transfer of control. Once an instruction is executed the control is passed to an interrupt handler which may change the environment for the next instruction. More than a single interpreter may be present. 4

Lecture 6 55 Figure 2.5 from the textbook

Lecture 6 6 Processors Can execute instructions from a specific instruction set Architecture  PC, IR, SP, GPR, ALU, FPR, FPU  State is saved on a stack by the interrupt handler to transfer control to a different virtual processor, thread. 6

Lecture 6 7 Interpreters are organized in layers Each layer issues instructions/requests for the next. A lower layer generally carries out multiple instruction for each request from the upper layer. 7

Lecture 6 88 Figure 2.6 from the textbook

Lecture 6 9 Example – a calendar management program Top layer a Java program with the following components:  The instruction reference  get the information provided by the keyboard and mouse and interpret them  The repertoire  add an event, delete an event, etc.  The environment  the files holding the current calendar Next layer  JVM which interprets the program  The instruction reference: next bytecode instruction  JVM instructions  The environment: IR, PC, etc Bottom layer  the computer the JVM is running on 9

Lecture 6 10 Figure 2.7 from the textbook

Lecture 6 11 Communication Links Two operations  SEND (link_name, outgoing_message_Buffer)  RECEIVE (link_name, incoming_message_Buffer) Message  an array of bits Physical implementation in hardware  Wires  Networks Ethernet Internet The phone system 11

Lecture 6 12 The Internet – an extreme example of what hides behind the communication link abstraction Internet Core and Edge The hardware  Router  Network adaptor Hourglass communication model Protocol stack It’s along way to Tipperary – the way a message squizes through protocol layers

Lecture 6 13 Internet Core and Edge

Lecture 6 14 Router

Lecture 6 15 Router supporting QoS (Quality of Service)

Lecture 6 16 The network adaptor

Lecture 6 17 Hourglass communication model

Lecture 6 18 Transport and Network Services

Lecture 6 19 Multiplexing and Demultiplexing

Lecture 6 20 Application, Transport, Network, and Data Link Layer Protocols

Lecture 6 21 It's a long way to Tipperary it's a long way to go!!

Lecture 6 22 From Local Area to Wide Area Networks

Lecture 6 23 Message delivery to processes

Lecture 6 24 Sockets and Ports

Lecture 6 25 Naming The tree abstractions manipulate objects identified by name. How could object A access object B:  Make a copy of object B and include it in A  use by value Safe  there is a single copy of B How to implement sharing of object B?  Pass to A the means to access B using its name  use by reference Not inherently safe  both A and C may attempt to modify B at the same time. Need some form of concurrency control.

Lecture 6 26 Binding and indirection Indirection  decoupling objects from their physical realization through names. Names allow the system designer to: 1. organize the modules of a system and to define communication patterns among them 2. defer for a later time to create object B referred to by object A select the specific object A wishes to use Binding  linking the object to names. Examples:  A compiler constructs a table of variables and their relative address in the data section of the memory map of the process a list of unsatisfied external references  A linker binds the external references to modules from libraries

Lecture 6 27 Generic naming model Naming scheme  strategy for naming. Consists of:  Name space  the set of acceptable names; the alphabet used to select the symbols from and the syntax rules.  Universe of values  set of objects/values to be named  Name mapping algorithm  resolves the names, establishes a correspondence between a name and an object/value  Context  the environment in which the model operates. Example: searching for John Smith in the White Pages in Orlando (one context) or in Tampa (another context). Sometimes there is only one context  universal name space; e.g., the SSNs. Default context

Lecture 6 28 Figure 2.10 from the textbook

Lecture 6 29 Operations on names in the abstract model Simple models: value  RESOLVE (name, context)  The interpreter: Determines the version of the RESOLVE (which naming scheme is used) Identifies the context Locates the object  Example: the processor Complex models support:  creation of new bindings: status  BIND(name, value, context)  deletion of old bindings: status  UNBIND(name, value)  enumeration of name space: list  ENUMERATE(context)  comparing names status: result  COMPARE(name1,name2)

Lecture 6 30 Name mapping Name to value mapping  One-to-One  the name identifies a single object  Many-to-One  multiple names identify one objects (aliasing)  One-to-Many  multiple objects have the same name even in the same context. Stable bindings  the mapping never change. Examples:  Social Security Numbers  CustomerId for customer billing systems

Lecture 6 31 Name-mapping algorithms 1. Table lookup 1. Phone book 2. Port numbers  a port the end point of a network connection 2. Recursive lookup: 1. File systems – path names 2. Host names – DNS (Domain Name Server) 3. Names for Web objects - URL – (Universal Resource Locator) 3. Multiple lookup  searching through multiple contexts 1. Libraries 2. Example: the classpath is the path that the Java runtime environment searches for classes and other resource files

Lecture Table lookup Figure 2.11 from the textbook

Lecture 6 33 How to determine the context Context references:  Default  supplied by the name resolver Constant  built-in by the name resolver  Processor registers (hardwired)  Virtual memory (the page table register of an address space) Variable  supplied by the current environment  File name (the working directory)  Explicit  supplied by the object requesting the name resolution Per object  Looking up a name in the phone book Per name  each name is loaded with its own context reference (qualified name).  URL  Host names used by DNS

Lecture 6 34 Dynamic and multiple contexts Context reference static/dynamic.  Example: the context of the “help” command is dynamic, it depends where you are the time of the command. A message is encapsulated (added a new header, ) as flows down the protocol stack:  Application layer (application header understood only in application context)  Transport layer (transport header understood only in the transport context)  Network layer (network header understood only in the network context)  Data link layer (data link header understood only in the data link context)

Lecture Recursive name resolution Contexts are structured and a recursion is needed for name resolution. Root  a special context reference - a universal name space Path name  name which includes an explicit reference to the context in which the name is to be resolved.  Example: first paragraph of page 3 in part 4 of section 10 of chapter 1 of book “Alice in Wonderland.”  The path name includes multiple components known to the user of the name and to name solver  The least element of the path name must be an explicit context reference Absolute path name  the recursion ends at the root context. Relative path name  path name that is resolved by looking up its mot significant component of the path name

Lecture 6 36 Example AliceInWonderland.Chapter1.Section10.Part4.Page3.FirstParagraph Most significant   Least significant

Lecture Multiple lookup Search path  a list of contexts to be searched Example: the classpath is the path that the Java runtime environment searches for classes and other resource files User-specfic search paths  user-specific binding The contexts can be in concentric layers. If the resolver fails in a inner layer it moves automatically to the outer layer. Scope of a name  the range of layers in which a name is bound to the same object.

Lecture 6 38 Comparing names Questions  Are two names the same?  easy to answer  Are two names referring to the same object (bound to the same value)?  harder; we need the contexts of the two names.  If the objects are memory cells are the contents of these cells the same?

Lecture 6 39 Name discovery Two actors:  The exporter  advertizes the existence of the name.  The prospective user  searches for the proper advertisement. Example: the creator of a math library advertizes the functions. Methods  Well-known names  Broadcasting  Directed query  Broadcast query  Introduction  Physical randezvoue

Computer System Organization Operating Systems (OS)  software used to  Control the allocation of resources (hardware and software)  Support user applications  Sandwiched between the hardware layer and the application layer OS-bypass: the OS does not hide completely the hardware from applications. It only hides dangerous functions such as  I/O operations  Management function Names  modularization Lecture 6 40

Lecture 6 41 Figure 2.16 from the textbook

The hardware layer Modules representing each of the three abstractions (memory, interpreter, communication link) are interconnected by a bus. The bus  a broadcast communication channel, each module hears every transmission.  Control lines  Data lines  Address lines Each module  is identified by a unique address  has a bus interface Modules other than processors need a controller. Lecture 6 42

Lecture 6 43 Figure 2.17 from the textbook