Please enable JavaScript.

Coggle requires JavaScript to display documents.

OS Support (Communication and invocation (RPC delay vs requested data size…

- - - - Users intelligently use networks commands and operations provided
      - Each host remains autonomous; can continue to operate when disconnected from the networking environment
      - Provides support for networking operations
      - Does not manage processes across the nodes
    - - Remove the need for the user to specify how the networking commands and operations should be undertaken
      - Provides a single system image
      - Each host may not have everything that would be required to operate on its own when disconnected from the network
      - Users never concerned with where their programs run, or the location of any resources
      - Has control over all the nodes in the system, and it transparently locates new processes at whatever node suits it scheduling policies
  - - - Hides details about the platform's internal operations
      - Provides a useful service interface for clients
    - - Ensures users cannot interfere with each other
      - Resources are not exhausted to the point of system failure
      - Protects resources from illegitimate access, other users and other clients that are using resources on the host
    - - Concurrently process all client requests -> all clients receive service
      - Achieved by time sharing
  - - - Handles the creation of processes (a unit of resource management)
      - Encapsulate basic resources of memory (address space) and processor time (threads)
    - - Handles the creation, synchronisation + scheduling of one or more threads for each process
      - Threads can be schedued to receive processor time
    - - Handles interprocess communication
    - - Handles allocation + access to physical and virtual memory
      - Provides translation from virtual to physical memory
      - Handles paging of memory
    - - Handles privileged operations - those that directly affect shared resources (e.g. to and from an I/O device)
      - Responsible for ensuring that the host continues to provide proper service to the client
- - - - Carried out by the client who has the right to perform them
      - Conform to resource policies of the host
      - Resources can be
        
        Visible: discovered by listing a directory contents or searching for it
        
        Invisible: Should be known a priori by the client; can be guessed
  - - - Carried out by the client who has the right to create a process
      - Enforce host based policies
  - - - Supervisor: instructions are capable of accessing and controlling every resource on the host
      - User: instructions are restricted by the processor to only those access defined/granted by the kernel
      - Changing between them is called a domain transition
    - - Kernel puts processor into user mode
      - Kernel assigns processor time to the user process
      - User process accesses a kernel resource using a system call - exception that puts the processor into supervisor mode and returns control to the kernel
- - - - Virtualisation: giving each process the maximum amount of physical memory available; swapping resources in and out from the disk if required
      - Paged virtual memory scheme divides the address space into fixed size blocks; located in RAM or in swap space on the hard drisk drive
      - Page table is used by the processor and OS to map virtual addresses to real addresses; contains access control bits for each page for access privileges
      - OS manages pages and swaps them in/out of memory in response to memory address accesses
  - - - Can be used to communicate with each other
      - Can be used for two identical objects being stored e.g. libraries, kernel
      - Faster: no overhead of marshaling, transmission and unmarshalling
      - Processes are not protected from each other
  - - - Faster
      - Shared in real memory
      - No actual copying of memory bytes
    - - Saves time when allocating new process
      - Saves space - only what is required is actually copied
  - - - Transfer policies: new process allocated locally or remotely
      - Location policies: which host, from a given set of host, the new process should be allocated on
    - - Static: do not take into account current state of the DS
      - Adaptive: receive feedback about DS current state
    - - Gathers info about DS current state
      - Can be
        
        Centralised: single load manager receives feedback from all other hosts in system
        
        Hierarchical: load managers arranged in a tree, internal nodes are load managers, leaf nodes are hosts
        
        Decentralised: A load manager for every host and load managers communicate with each other directly
      - Types of allocation policies
        
        Sender-initiated / push policy: local host responsible for determining the remote host to allocate the process; good when there is low load + random selection
        
        Receiver-initiated/ pull policy: remote host advertises that new processes can be allocated to it; better for high load + random selection
    - - Do this by copying their address space
      - Processes are often CPU dependent -> difficult to migrate
        
        Ensure that hosts are homogenous
        
        Use virtual machines by avoiding CPU dependent instructions
      - Process may be using host resources e.g. open files and open sockets -> difficult to migrate
- - - - Desgin choice of new kernels: leave implementation of networking protocols to servers -> easier to choose networking protocol
      - Kernel required to provide device drivers for new networking devices
        
        Transparently select appropriate device driver
        
        Middleware dynamically select
  - - - Used when client and server exchange info in a single session for a reasonable length of time
      - E.g. telnet, ssh
      - Limited if end-points are changing their identity (e.g. mobile clients)
    - - Used for request-reply application that do not require a session for any length of time
      - E.g. finding the time from a time server
      - Less overhead -> use for applications that require low latency (e.g. streaming media, online games)
  - - - Timeout: sufficient for a client-server on the Internet but long delays on mobile devices
      - Persistent asynchronous invocation
        
        Client side: placed in queue at the client and attempts are made to complete the request as the client roams from network to network.
        
        Server side: response is put into a client mailbox and the client is required to retrieve the response when it can
        
        Allows user to select which kind of network will be used to service the request (e.g. queued RPC)
- - - - Changing kernel functionality more difficult than changing server functionality
      - Less system calls + interprocess communication minimised -> faster
      - Less reliable: If one layer fails, entire kernel cannot be used
      - E.g. Unix OS
      - Provides diverse functionality
    - - Greater extensibility
      - Better ability to enforce modularity behind memory protection boundaries
      - Small kernel is more likely to be free of bugs
      - Supports middleware via subsystems
      - E.g. Mach OS
      - Have to swap in and out which is expensive
- - - - Server creates a fixed number of threads (worker pool)
      - Request arrive at server -> put into queue by I/O thread -> assigned next available worker thread
      - Request priority
        
        Handled by using a queue for each kind of priority
        
        Worker threads assigned to high priority requests before low priority requests
      - Bottleneck
        
        I/O
        
        Number of workers too few to handle the rate of requests
      - Queue is shared -> overhead
    - - Separate thread created by the I/O thread for each request
      - Thread is deallocated when the request is finished
      - Num Threads = num requests in the system
      - Advantages
        
        Potential parallelism maximised
        
        Avoids accessing a shared queue
      - Disadvantages
        
        Thread allocation + deallocation incur overheads
        
        As num threads increase, advantages from parallelism decreases (for a fixed number of processors) -> overhead in context switching between threads can outweight benefit
        
        Managing large numbers of threads can be more expensive than managing a queue
    - - Separate thread allocated for each connection
      - Reduces overall number of threads
      - Client can make several requests over the single connection
    - - Worker t hread is associated for each remote object or accessed resource
      - I/O thread receive request -> queue them for each worker thread
  - - - Cheaper to allocate/deallocate
      - Easy to share resources via shared memory
      - Require only a new processor context
      - Context switching between threads is cheaper
      - Faster switching
    - - Require a new address space -> a new page table
      - Context switching is more expensive -> cache behaviour with address spaces
        
        Save the processor's original state and loading the new state
        
        Changing from user to kernel context -> change protection mode, which is called a domain transition
      - Processor context: values of the processor registors
        
        Program counter
        
        Address space ID
        
        Processor protection mode (supervisor / user)
    - - Synchronisation overhead of shared data
      - Shared process memory space
      - Program debugging (synchronisation, non-deterministic timing, accidental data corruption)
  - - - Preemptive: running thread is suspended any time to allow processor time for other threads; usually periodically
      - Non-preemptive: running thread will continue to receive processor time until the thread yields control back to the thread scheduler
        
        Concurrency issues greatly simplified
        
        Might lead to starvation: no guarantee other threads will receive processor time -> lower performance and usability
    - - Kernel may be able to allocate threads (kernel threads)
        
        Context switching is slower
        
        Limited on number of allocated kernel threads
      - If no kernel threads, user can manage user threads within a process
        
        Kernel gives processor time to the process -> process schedule threads
        
        Cannot take advantage of multiple processors
        
        If causes a page fault, will block entire process + all other threads in that process
        
        User threads within diff processes cannot be scheduled according to a single scheme of relative prioritisation
        
        Context switching is faster
        
        User thread scheduler can be customised by the user to be specific for the given application ->can usually allocate more threads than kernel threads
      - Possible to combine both kernel and user level threads