Status

[Akhil S]

Hi Team,

Was just curious to know the status of the project.

If possible, can someone please update it on this thread.

Thanks in advance :-)

Warm Regards,

Akhil S

[Murali Krishnan]

Hai Akhil and everyone,

  I was planning to update at the end of the semester. 

  The design is almost through, we are working on the design of the final stage - swapping.  Part of the work is already documented,

and fortunately we have a reasonably simple design, which means the implementation is going to be far less complex than even the
present xos (not because the work is simple, but because the module functions already implemented in previous stages).   

  The roadmap too is almost through, except for the final stage on swapping. (pls. have a look at the site:  exposnitc.github.io t have

a feel for yourself). 

   We also have decided to work on the next year to add 1)  disk commit consistency (avoid the file system getting into inconsistent state if there is a crash).

2) add one more core to the system.  This requires work on the XSM simulator and rewriting machine specification, but once that is done, the original OS

design is likely to go through with minor changes. 

Murali

 

[Akhil S]

Thanks for the update sir.

I took a quick look through the roadmap and it looks excellent, esp the new diagrams.

My personal opinion is that adding multiprocessing capabilities to the system would significantly increase the difficulty of the exercise
(eg Most of the memory access would be critical and hence spinlocks etc have to be introduced). 

But at the same time, I am excited to see it too :-)

--

Regards,

Akhil S

[Murali Krishnan]

Dear Akhil,

  Actually, it may not be so complicated. 

1.  The boot process requires a bit of careful design because you need to decide from what point (of time as well as
address) the second processor that shares the common memory (that is, non-boot) can start simultaneous execution.

The machine will have one boot processor and then the "second core" starts execution when the first core executes a "start" instruction. 

Normally, there is also mechanism to initialize the IP value of the secondary when it starts (it could be a preset value - say instruction 256
in the boot ROM.  The boot ROM can contain code to Jump to some OS that can setup the registers of the secondary and run say idle process - it

doesn't hurt if both run idle in parallel).   

Thus the boot processor sets up the OS in memory and sets up the secondary so that it starts with the idle process.

 

2.  Once that part is taken care of, then, the support from the architecture will be sufficient to synchronize execution.  Basically, the idea
is the following: 
  The machine will have an instruction pair (sync, unsync) to support multiprocessor operation.  When the sync instruction is executed by

one of the processors, the other waits till it executes unsync.  (The hardware is capable of resolving race conditions arising out of both trying

to run synch at the same time). 

   With this support, now the simplest design is to have the rule "modify the OS so that whenever execution enters kernel mode, do "sync"
and do "unsync" when leaving kernel mode.  Of course, this is not efficient.  But the basic idea is already there. 

3.  The are some details.  For instance, the state of a process must now indicate which core it has been scheduled

(Running-1, Running-2 etc.  for idle, a state "Running-on-Both" might be needed!). 
Generally one must  ensure that the processors 'sync' before either one tries to run the scheduler. 

Otherwise, it will be enough to 'sync' before acquiring a resource.  Since the resource request sequence has been planned in a way

to avoid circular wait, deadlocks can't occur even with two processors. 

4.   A common hardware model with two core processors is to have I/O operations interrupt only the secondary.  
That is, all interrupts (except timer) will interrupt only the secondary.  This changes nothing, because our current design does not

require interrupts to execute in the context of the process which initiated the disk/console operation. 

5.  There will be some work at shut down time as well, basically to figure out "who should shut down..". 

 

[Akhil S]

Let me reiterate what I understood. Please correct me if I am wrong.

So there would be a kernel-wide lock instead of locking each data structure per se.

The sync-unsync model ensures that there is no parallelism within the kernel, reducing it to our current model.

The design, though not efficient, is simple enough to implement.

I just have a doubt - what exactly happens to the processor while it waits after executing sync? 

I am assuming it goes to a busy wait condition.

Also the sync must be a test-and-set type of lock, handled by the hardware as you have mentioned. 

It also helps students understand that concept, which is missing from the current exercise.

Does each processor have its own timer mechanism, having a different timer model could increase the efficiency.

Overall, I am convinced that the implementation is plausible.

Akhil

--

Regards,

Akhil S

[Murali Krishnan]

Actually I do have in mind a more complex implementation than "only one processor can go in kernel mode at one time".

Basically, before Acquire Inode, Acquire Buffer, Acquire Disk and Acquire Terminal, a  "sync" operation has to be done.
But for this, the processors can execute in kernel mode in parallel. 

Sync is an abstraction for spin lock.  Basically, it executes a TSL instruction in a busy loop.    The hardware instruction TSL (which is an

atomic test and set instruction) requires locking the data bus for two instruction cycles (for test and set) ,
which modern multiprocessors are capable of. 

Each processor may be assumed to have a separate timer.  Even the clock speeds need not be the same. 

[Akhil S]

Sync operation has to be done before any critical memory access too right

For eg the following scenario:
Both processors hit timer, both schedule the same process to run.

--

Regards,

Akhil S

[Murali Krishnan]

Yes, yes, I forgot to include that.   sync has to be done before running the scheduler.

We will also need sync operation before memory/disk block allocation in memory manager module.   (The present memory manager module

is not designed for parallel execution). 

Generally care has been taken in the present design to guard against two processes operating on the same file concurrently.  (though a bit too

conservative for single processor system).  But, due to this, serious complications are unlikely with file data structures in parallel execution. 

There will be some care needed when running the paging module.  (swap module)