Reason for printing of numbers in arbitrary order - Stg20

38 views
Skip to first unread message

govindu c.j.v.s.kasyap

unread,
Oct 23, 2020, 11:22:13 AM10/23/20
to XOS Users
In stage 20,2020-10-23 18_56_06-Window.png
Here, what exactly is the reason the numbers are to be printed arbitrarily, is it because due to the fact that when one process acquires the terminal, its set to WAIT and other processes are scheduled and this may lead to arbitrary number of instructions executed? But as Terminal gets blocked once its acquired by parent initially and then child ,so shouldn't always the outputs of the both process be printed alternatively(parent and child)? And also how does varying timer value in XSM effect the above scenario? It gave different order of outputs with larger and lesser value of timer (Screenshots attached below). As far as I understand, the RR scheduling algorithm is based on time quanta (here its certain number of user instructions) allocated for each process, so shouldn't it be giving a constant output all the time due to above reasons? Is there anything wrong in my approach? Could someone explain briefly? Also, how does this vary vary with real-life implementations of OS as better algorithms than RR are being used (or doesn't it matter?)

Below screenshots are for Stg-20,ASSG-1 question along with INIT code [ Varying outputs with different timer values]
2020-10-23 20_38_30-Window.png
   
2020-10-23 20_33_42-Window.png
2020-10-23 20_48_32-Window.png
2020-10-23 20_31_29-Window.png

Murali Krishnan

unread,
Oct 23, 2020, 11:55:03 AM10/23/20
to xos-...@googlegroups.com
Kashyap,
  After one program executes n number of user instructions (set by --timer option of xsm simulator), a timer interrupt occurs.
  Since you run the scheduler, execution passes to the other process (unless it is in wait state).   
  Since write involves no wait, during each timer interrupt, alternate switching happens between the two processes.  
  If the switch runs very symmetrically, then printing might happen in the order 1,2,3,4....
  To break the sequence, in (only) one of the processes, just add a loop i = 1 to 100 do nothing. 
  You must do this after the semaphore is released, before it is acquired again.
  With this, one process will acquire semaphore and print numbers at a slower rate than the other.
  Hence you must expect the faster process to print several numbers from the list between two prints of the slower process. 
  Even after doing this, if your program prints numbers sequentially, then there is something wrong elsewhere. 
Murali
  

--
You received this message because you are subscribed to the Google Groups "XOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xos-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-users/d78c6248-ba0e-4fa2-aa43-9837ed695d71n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages