additions to proj2 documentation about synchronization

1 files changed, 15 insertions, 17 deletions

diff --git a/proj2.txt b/proj2.txt
index 8bbd521..ab96337 100644
--- a/proj2.txt
+++ b/proj2.txt
@@ -59,9 +59,11 @@ actual page-loading is done when a page-fault occurs.
 >> A3: How do you deal with or prevent page faults in file system
 >> routines. Argue why your solution is deadlock free.
 
-As we do not have any global structures, that means they are per process and
-per thread, page faults can not happen. The same argument goes for the
-question of being deadlock free.
+All system calls assert that a page fault can never occur while the
+file system is locked. As for this reason syscall_read uses a temporary page
+as buffer which is copied into user space after the filesystem is unlocked
+again. This means if a page fault occurs during copying the file system is not
+locked an therefore this cannot create a deadlock.
 
                       STACK GROWTH
                       ============
@@ -79,7 +81,7 @@ extern void *syscall_sp   ...stored stack pointer for the "page fault inside
 >> B2: Describe how you integrated the (potentially growing) stack segment
 >> into your page table management implementation.
 
-The stack growth itself gets triggered by the page fault handler just as the
+The stack growth itself is triggered by the page fault handler just as the
 lazy loading of pages. Other than that there's no association between the pages
 of the stack and the pages of segments/mmapped files.
 So pages of the stack don't get tracked inside the page table at all!
@@ -115,27 +117,24 @@ struct mmap_table_entry:
   struct file *file;      ...file handle
   int pages;              ...number of pages the mapping needs
 
-struct page_table_entry:
-  union struct TODO       ...structure needed for loading of memory mapped files
-
 ---- ALGORITHMS ----
 
 >> C2: Describe how memory mapped files integrate into your virtual
 >> memory subsystem.
 
-For every memory mapped file we create a new per process mmap table. Its entries contain
-the virtual address of the first memory mapped file, the file handler and the number
-of pages which are needed for the mapping. Additionally we store the lowest
-free index, the highest used index and the capacity of the mmap table. We then
-create for ever page required by the memory mapped file a new page table
-entry.
+For every page required by the memory mapped file we create an associated entry
+in the page table. It contains the first virtual address of the memory mapped file,
+the file handler and the number of pages which are needed for the mapping. 
+Additionally we store the lowest free index, the highest used index and the
+capacity of the mmap table. We then create for every page required by the 
+memory mapped file a new page table entry.
 
 >> C3: Explain how you determine whether a new file mapping overlaps
 >> any existing segment.
 
 We avoid overlaps of file mappings by determining in the systemcall which tries
 to map a file if the required number of pages for the mapping are still free.
-To obtain this information we lookup if there are entries in the page table
+To obtain this information we lookup the entries in the page table
 that imply that the memory space needed for the mapping is occupied by other
 pages. Furthermore we must check if any page not in the page table (for
 instance loaded pages on the stack) occupies the space we want to map our file
@@ -151,9 +150,8 @@ to.
 >> the two situations.
 
 As our implementation of the supplemental page table does not distinguish
-pages that came from memory mapped files and pages from executables, both the
-supplemental page table as the memory mapped file table can share the page
-table routines.
+between pages of memory mapped files and pages of data segments they share 
+the same insert and loading code.
 
                      SURVEY QUESTIONS
                      ================