**THE NUCLEUS of a MULTIPROGRAMMING SYSTEM**
============================================

# ABSTRACT
Goals:
- don't limit the OS design
- allow for extension
- make no assumption about how the OS is used
Solution:
provide just a fundamental set of primitives (creation, control of hierarchy
of processes, communication between process), from that OSes can be built.
Each OS can have diverse strategies of program scheduling and resource 
allocation


# 1. INTRODUCTION
- current (long back before, remember) system is not flexible: i.e hard to 
  change the policy (i.e. mode of operation the system control)
- Goal: provide a system nucleus what can be extended with new OSs in 
  an orderly manner.

# 2. SYSTEM NUCLEUS
- no assumptions about how the OS is used (i.e the policy)
- concentrate on fundamental aspects of the control of environment  consisting
  parallel, cooperating processes
	+ process creation
	+ process hierarchy
	+ process communication
- these are mechanisms that OS can be built on, each OS may have it own policy
  on process scheduling, resource allocation and so on.

# 3. PROCESSES
- program in execution
- has a unique process name (like Unix PID)
- 2 types: 
	+ internal (typical process)
	+ external (I/O device)

# 4. PROCESS COMMUNICATIONS
- Why not use semaphore as a synchronization mechanism?
	+ not flexible, i.e, not allow to build independent component.
	What if a process holding a lock and die?
- Instead use message passing
	+ a process can die, doesn't need to care about other, allow to build
	independent component
	+ more protection
- Mechanism Details:
  + each process has a message queue
  + system nucleus has a message buffers
  + 4 primitives

Send Message (receiver, message, buffer)
----------------------------------------
- copy message into the first available buffer within the pool and delivers
  it in the queue of named receiver
- the receiver is activated if waiting on a message
- Sender continues after being informed of the *identity of the message buffer*
  (why this is important, because later on, answer if any will be sent back
   using that message buffer ==> connection set up)

Wait Message(sender, message, buffer)
-------------------------------------
- delay requesting process until a message arrives in the process's queue
- on return, i.e when process is ready to proceed), it is supplied:
	+ name of sender
	+ contents of message
	+ identity of the message buffer (why need this? ok, later on, we will
	  see some kind of piggy back, the same message buffer will be used
	  to store the answer. So this identity is some kind of connection
	  between sender and receiver)
	+ the buffer is removed from the queue, and made ready to transmit answer

Send Answer(result, answer, buffer)
-----------------------------------
- copy an answer in which message has been received (the identity in charge...)
- deliver it to queue of original sender (there is no sender name in the
  call, how do i know what is original sender? again by the identity of message
  buffer given when call WAIT MESSAGE)
- the answering process continues immediately
- the sender of the message is activated if it is waiting for the answer
- Question: what is result? (see later, but for now, some kind of status)

Wait Answer(result, answer, buffer)
-----------------------------------
- delays the requesting process until answer arrives in a given buffer
  (hence, send message need to know the identity of message buffer where
   the message was sent, so that it know where to wait on)
- On arrival, the answer is copied into the process, and the buffer is
  returned to the pool.
- Result: specify whether the answer is:
	+ response from another process or
	+ dummy answer generated by system nucleus in case of non-existing receiver

Features (or advantage of this communication model):
----------------------------------------------------
- process independent of each other: process appear and disappear any time
  (vs. THE: process depends on each other, because communication on semaphore)
- *conversation ID or connection establishment*
  selection of a message buffer as an identification of a conversation
  (remember the message ID... But question: is this imply that 2 process can
  only communicate sequentially, one after another? in other word, can 
  process A send 2 messages at a time to process B? I guess yes, in this case
  process A will know 2 id of 2 buffer ..., and it is like 2 distinguish
  conversation between A and B)
- *protection*
  + what if a process is malicious? I.e it want to interfere with conversation 
    between two other processes.
  + Solution: store name of sender and receiver in each buffer, and check
    when send or wait for an answer in a given buffer.
  + Kernel involves in message buffer management:
- Efficiency:
  + because we have buffer queue ...
  + if not, there will be synchronous communication, which is slow

*Drawback*
- size of buffer pool is limit
- a malicious process can overwhelm the pool of buffer
- solution: limit the number of message a process can send at a time.

# 5. EXTERNAL PROCESS
- like device driver
- exclusive access: 
  + nucleus 2 primitives: reservation and release (like lock/unlock)
- clock process: important
- external process: can be used to
  + synchronization between internal process (say send a message to clock 
    process)
    e.g. send a message to watchdog process, receive answer when file system
    is mounted.

# 6. CONTROL (on internal process)
Nucleus provides mechanism to:
- create a process
  + storage area must be within parent's own area
- parent can start/stop a child process
- parent can remove a child process in order to assign its storage area to 
  other process    
==> parent has complete freedom to choose its own strategy of scheduling 
among its children (decide on policy ...)
(==> loading and swapping are not part of nucleus)

This way, a process hierarchy can be created, and each process is an OS 
of its children. Parent have complete control over it child.
See Remzi note for one example


What is the drawback of Nuclues?
- MPI, slow...
- too general...