A Brief Discussion on Operating System Organization CS3013

A Brief Discussion on Operating System Organization CS-3013 & CS-502, Summer 2006 Operating System Organization 1

The “THE” Operating System Operator User Programs I/O Management Operator-Process Communication Memory Management Processes & Semaphores Dijkstra, E. W. , “The Structure of the ‘THE’-Multiprogramming System, ” Communications of ACM, vol. 11, pp. 341 -346, May 1968. (. pdf) CS-3013 & CS-502, Summer 2006 Operating System Organization 2

Operating System Organizations • The literature in operating systems is full of papers of simple, elegant systems like this one • Simple • Easy to build and maintain by small teams • Very instructive for study • Limited usefulness CS-3013 & CS-502, Summer 2006 Operating System Organization 3

Question • In a typical system, how do the layers or components talk to each other? • Answer: one of two ways • Messages between processes • Procedure/function calls between “modules” CS-3013 & CS-502, Summer 2006 Operating System Organization 4

Message-based systems • Processes are isolated from each other – separate address spaces, etc. • IPC primitives • Send Message (socket, content) • Wait For Message (socket, &content) • Requests, results, and status encoded in message contents • Static processes to manage resources, create abstractions and layers CS-3013 & CS-502, Summer 2006 Operating System Organization 5

Message-based systems – Typical Resource Manager <internal data for managing resource> while (true) { Receive. Message (socket, &content) switch (content. action) { case action 1: <do something & reply> case action 2: <do something else> case action 3: <hold pending some event> case action 4: <release previously held action & reply>. . . } } CS-3013 & CS-502, Summer 2006 Operating System Organization 6

E. g. , File Manager void File_Manager(socket file. Socket) { <internal data for managing files> while (true) { Receive. Message (file. Socket, &content) switch (content. action) { case write: <start or queue write operation> case seek: <start or queue disk arm motion> case read: <start or queue read operation> case write. Done: <return acknowledgement> case read. Done: <return result of previously started read operation>. . . } } } CS-3013 & CS-502, Summer 2006 Operating System Organization 7

Message-based systems (continued) • Resource manager • Infinite loop • Created at system start-up, assigned fixed sockets • Effectively a critical section – one request or activity is handled at a time • Maintains internal data structures for queuing up requests that cannot be replied to immediately • No sharing of data with requesting processes • Status information encoded in message content • Reply to specific socket of requester CS-3013 & CS-502, Summer 2006 Operating System Organization 8

Message-based systems (continued) • Requested actions encapsulated in function – e. g. , void read(file f, char *p, int len) { socket s = new(socket); content c = {f, read. Action, len, s}; content r = {char c[len]); Send. Message(file. Manager, c); Wait. For. Message(s, &r); strcpy(r. c, p, len); } • Examples • MACH (Carnegie Mellon University) • Mac OS-X CS-3013 & CS-502, Summer 2006 Operating System Organization 9

Procedure/Monitor-based systems • Resource Manager represented as a Monitor – e. g. , monitor class file { <internal data for managing files> void read(file f, char *p, int len); void write(file f, char *p, int len); void seek(file f, position); . . . } • Requester makes direct function calls to monitor • Implies monitor is same address space CS-3013 & CS-502, Summer 2006 Operating System Organization 10

Process/Monitor systems • Resource manager • Static object with functions; created at start-up • Effectively a critical section – one request or activity is handled at a time • Maintains internal data structures for queuing up requests that cannot be replied to immediately • Shared address space, but internal data hidden from requesters • Status maintained in stack of requesting process • Examples • Pilot CS-3013 & CS-502, Summer 2006 Operating System Organization 11

Requested Actions • Monitor function calls look just like calls to encapsulating functions in Message system – E. g. , – void read(file f, char *p, int len); • May either send a message or enter a monitor! • Caller does not know the difference CS-3013 & CS-502, Summer 2006 Operating System Organization 12

Observation • There is really no fundamental difference between systems organized by messages and those organized by monitors • Choice depends upon what is available in underlying system • Shared or separate address spaces • Language support for monitor discipline • … Lauer, H. C. and Needham, R. M. , “On the Duality of Operating System Structures, ” Operating Systems Review, vol 13, #2, April 1979, pp. 3 -19. (. pdf) CS-3013 & CS-502, Summer 2006 Operating System Organization 13

Next Topic CS-3013 & CS-502, Summer 2006 Operating System Organization 14