1. COT 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00 – 6:00 PM

2. Last time:  Networking- the Internet  Naming; Use by: value/name Today: Binding and indirection Generic naming model  Name mapping algorithms  Comparing names; name discovery Practical design of naming scheme  Contexts  Name overloading Next time  UNIX File System Lecture 8 – Tuesday, February 8, 2011 Lecture 82

3. Naming The three 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. 3

4. Lecture 8 Binding and indirection 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 Indirection  decoupling objects from their physical realization through names. 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 4

5. Lecture 8 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 5

6. Lecture 8 Figure 2.10 from the textbook 6

7. Lecture 8 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) 7

8. Lecture 8 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 8

9. Lecture 8 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 9

10. Lecture 8 1. Table lookup Figure 2.11 from the textbook 10

11. Lecture 8 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 11

12. Lecture 8 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) 12

13. Lecture 8 2. 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 13

14. Lecture 8 Example AliceInWonderland.Chapter1.Section10.Part4.Page3.FirstParagraph Most significant   Least significant 14

15. Lecture 8 3. 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-specific 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. 15

16. Lecture 8 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? 16

17. Lecture 8 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 17

18. Practical design of naming schemes Transition from abstract models to practical ones. Name conflict  multiple modules have the same name. How to avoid name conflicts when modules are developed independently often by different individuals? The theoretical model tells us that we must specify a context for name resolution; but this is not so straightforward!!  Example: there are two versions of module A; one is used by module B and the other by module C. Conflict when module B uses C. Lecture 818

19. Figure 3.1 Single context  ambiguity WORD_PROCESSOR  (INITIALIZE,SPELL_CHECK) SPELL_CHECH  (INITIALIZE) (but a different version of it) Lecture 819

20. Figure 3.3 Two distinct contexts  how does the interpreter choose the context? It needs a basis for the contexts. Lecture 820

21. Figure 3.4 Add a context reference to each module telling the interpreter which context to use for that module? Not feasible to tinker with someone else’s modules. Lecture 821

22. Figure 3.5 Have separate contexts but establish a link between them; the link points to the new context for the shared object Lecture 822

23. An elegant solution We need a systematic rather than ad-hoc ways to deal with the problem because programs contain many references to objects. Solution  associate the name of the object not with the object itself but with a structure consisting of pairs (original object, context). Some programming languages implement such a structure called closure and use static references. File systems rarely apply this solutions. Lecture 823

24. Metadata and name overloading Metadata  information about an object that  is useful to know about the object but cannot be found inside the object  may be changed without changing the object, e.g., the last date a file was referenced. Examples:  A user-friendly name; e.g., quadratic_solver  /user/local/bin/ linpack/quad.exe  The type of an object: e.g., Lecture9.ppt Where to place metadata?  In the same place with the data; e.g., the Unix file system stores metadata in inodes  In a separate place  process control block stored in the kernel space.  Overloading the name  e.g., Lecture9.ppt Overloading  adding metadata to a name  Contradicts the principle that names should only be used to reference objects  Creates a tension between the need to keep the name unchanged and the need to modify overloading information. Lecture 824

25. Names and overloading Pure names  names with no overloading. Fragile names  overloaded names which violate the idea of modular design. E.g.., adding location information on the file name. Opaque name to a module  the name has no overloading the module knows how to interpret.  A name may pass through several modules before reaching a module which knows how to interpret it. Lecture 825

26. Addresses Address   A name used to locate an object  Not a pure name it is overloaded with metadata  Parsing an address provides a guide to the location Often chosen from a compact set of integers  Does address adjacency correspond to physical adjacency? True in some cases; e.g., sectors on a disk False in other cases; e.g., the area code of a phone number  Can we apply arithmetic operations to addresses? Yes in some cases; e.g., memory references No in other cases; e.g; telephone numbers (actually the phone numbers do not forms a dense set!!) Remember that overloading the causes name fragility Lecture 826

27. Changing addresses Changing addresses not hidden by a level of indirection is tricky. Solutions 1. Search for all addresses and change them 2. Make each user do a search for the object and if the search returns “object not found” detect that the address has been changed and supply the new address. 3. If possible bind the object to both the old and the new name 4. If the name is bond to an active agent place a forwarding scheme to the old address. The optimal solution  hide an address under a level of indirection. We’ll discuss DNS, domain name services that map host names to IP addresses. Lecture 827

28. Unique names Problems arise when names must be generated at a high rate., e.g., for online banking transactions (billions a week). Danger of name collision. Solution  Using a fine timestamp  read a fine digital clock (say with a resolution of microseconds) and convert the binary representation of the timestamp to a string of characters.  Use a random number generator with a very large name space.  For objects with a binary representation (e.g., files, images) use the object itself.  Hashing algorithms such as SHA (Secure Hash Algorithm) avoid the problem of long names. HSA produces names of fixed length. Lecture 828

29. Hierarchical naming schemes Think about naming in the Internet with hundred millions of hosts.  Unfeasible with a central authority.  Domain names  E.g., boticelli.cs.ucf.edu How to relate a hierarchical naming scheme used by Internet with the flat naming schemes used for MAC addresses?  MAC addresses do not have any overloading  ARP  RARP  DHCP Lecture 829

30. 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 830

31. Lecture 8 Figure 2.16 from the textbook 31

32. 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 832

33. Lecture 8 Figure 2.17 from the textbook 33

34. Bus sharing and optimization Communication  broadcast Arbitration protocol  decide which module has the control of the bus. Supported by hardware:  a bus arbiter circuit  distributed among interfaces – each module has a priority  daisy chaining Split-transaction  a module uses the arbitration protocol to acquire control of the bus Optimization:  hide the latency of I/O devices Channels  dedicated processors capable to execute a channel program (IBM) DMA (Direct Memory Access)  Support transparent access to files: Memory Mapped I/O Lecture 834

35. Optimization Direct Memory Access (DMA):  supports direct communication between processor and memory; the processor provides the disk address of a block in memory where data is to be read into or written from.  hides the disk latency; it allows the processor to execute a process while data is transferred Memory Mapped I/O:  LOAD and STORE instructions access the registers and buffers of an I/O module bus addresses are assigned to control registers and buffers of the I/O module the processor maps bus addresses to its own address space (registers)  Supports software functions such as UNIX mmap which map an entire file. Swap area: disk image of the virtual memory of a process. Lecture 835

36. DMA Transfer 36 Lecture 836

37. B. The software layer: the file abstraction File: memory abstraction used by the application and OS layers  linear array of bits/bytes  properties: durable  information will not be changed in time has a name  allows access to individual bits/bytes  has a cursor which defines the current position in the file. The OS provides an API (Application Programming Interface) supporting a range of file manipulation operations. A user must first OPEN a file before accessing it and CLOSE it after it has finished with it. This strategy:  allows different access rights (READ, WRITE, READ-WRITE)  coordinate concurrent access to the file Some file systems  use OPEN and CLOSE to enforce before-or-after atomicity  support all-or-nothing atomicity  e.g., ensure that if the system crashes before a CLOSE either all or none of WRITEs are carried out Lecture 837

38. Open and Read operations 38 Lecture 838