Hi Team,
Currently, in the get_code_page function of the Memory Manager module,
we iterate through all the disk map table entries of all processes to check if there is a valid loaded memory page for the corresponding disk block. If one exists, we return that page number.
However, while running forks.xsm in Stage 21 (Assignment 2), I observed that even though the same code is being executed by eight different processes, some of them use different code pages.
Upon debugging, I found that when the first process invokes get_code_page, it enters the disk load phase. Meanwhile, if other processes invoke the same function with the same block number before the first load completes, each of them allocates a new page and waits for the disk load. This continues until the first get_code_page call finishes and updates its page table. After that, the remaining processes start using the page from that page table.
This behavior leads to multiple loads of the same code block into memory.
To mitigate this issue, we can modify get_code_page to check the Disk Status Table upon entry. If the disk loader is already loading the same block, we should change the current process’s state to WAIT_DISK and call the scheduler. Once control returns from the scheduler, the process can use the memory page recorded in the Disk Status Table.
Proposed Algorithm:
if (blockNum == [DISK_STATUS_TABLE + 3] && [DISK_STATUS_TABLE] == 1) then
  pageNum = [DISK_STATUS_TABLE + 2];
  [PROCESS_TABLE + [SYSTEM_STATUS_TABLE + 1]*16 + 4] = WAIT_DISK;
  multipush(used registers);
  call SCHEDULER;
  multipop(used registers);
  R0 = pageNum;
  [MEMORY_FREE_LIST + R0] = [MEMORY_FREE_LIST + R0] + 1;
  return;
endif;
--
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, visit https://groups.google.com/d/msgid/xos-users/e55b9d6d-1d47-49b8-96ce-5233b381cfd8n%40googlegroups.com.