xxyzz / ostep-hw

Operating Systems: Three Easy Pieces(OSTEP) homework and project solutions

OSTEP-HW

Operating Systems: Three Easy Pieces homework solutions

CS-537 videos

Requirements

• Unix-like operating system

• Clang/GCC

• LLDB/GDB

• Valgrind

• Gawk

• Python

• 🐈

ostep-projects

C/Linux Projects and Kernel Hacking Projects (xv6)

Chapters

Virtualization

4. The Abstraction: The Process

5. Interlude: Process API

6. Mechanism: Limited Direct Execution

7. Scheduling: Introduction

8. Scheduling: The Multi-Level Feedback Queue

9. Scheduling: Proportional Share

10. Multiprocessor Scheduling (Advanced)

11. Summary Dialogue on CPU Virtualization

12. A Dialogue on Memory Virtualization

13. The Abstraction: Address Spaces

14. Interlude: Memory API

15. Mechanism: Address Translation

16. Segmentation

17. Free-Space Management

18. Paging: Introduction

19. Paging: Faster Translations (TLBs)

20. Paging: Smaller Tables

21. Beyond Physical Memory: Mechanisms

22. Beyond Physical Memory: Policies

Concurrency

26. Concurrency: An Introduction

27. Interlude: Thread API

28. Locks

29. Lock-based Concurrent Data Structures

30. Condition Variables

31. Semaphores

32. Common Concurrency Problems

33. Event-based Concurrency (Advanced)

Persistence

37. Hard Disk Drives

38. Redundant Arrays of Inexpensive Disks (RAIDs)

39. Interlude: Files and Directories

40. File System Implementation

41. Locality and The Fast File System

42. Crash Consistency: FSCK and Journaling

43. Log-structured File Systems

44. Flash-based SSDs

45. Data Integrity and Protection

46. Summary Dialogue on Persistence

47. A Dialogue on Distribution

48. Distributed Systems

49. Sun’s Network File System (NFS)

50. The Andrew File System (AFS)

License

This work is licensed under the GPLv3 or any later version.

ostep-hw's Issues

Questions about initial-xv6 project

This project requires counting the number of calling the read function by all processes, I notice that your implementation may only consider parent process and its child processes. is there a bug in it?

The first question in ch20: your answer: two, three. I think just one register is ok. PDBR->PDE->PDE->PTE

Question about homework for chapter6

Thanks for creating this repo.

I have one dumb question about the homework in chapter6 for measuring context switch time. For each loop, there should be 2 context switches happen right. One from parent to child and one from child back to parent, in this case should the real time be the final answer divide by 2?

Appreciate for any explanation.

29/hand-over-hand-locking-list.c has data race when inserting node

Hi there,
First, I want to thank you for this amazing repo which helps me a lot.

static void List_Insert(list_t *L, int key) {
  // synchronization not needed
  node_t *new = malloc(sizeof(node_t));
  if (new == NULL)
    handle_error_en(errno, "malloc");
  new->key = key;
  Pthread_mutex_init(&new->lock, NULL);

  // just lock critical section
  pthread_mutex_t *tempLock = &L->head->lock;
  Pthread_mutex_lock(tempLock);
  new->next = L->head;
  L->head = new;
  Pthread_mutex_unlock(tempLock);
}

This snippet of code does not eliminate the race condition when there are more than two threads inserting nodes to the list. Imagine thread_1 and thread_2 try to lock the head of the list and only one thread succeded. The other thread is blocked but holding the same head node as the other thread. After the thread(which successfully locked the head node of the list) inserting a new node into the list, what the blocked thread should do is locking the new head. But it will insert a node as the predecessor of the old head node.

I think we still need a global lock for inserting nodes into the list.

/initial-reverse/reverse.c

I have a question.

if ((head->line = malloc(linecap)) == NULL) { fprintf(stderr, "reverse: malloc failed\n"); exit(EXIT_FAILURE); }
when malloc failed. head won't be free

more concise barrier.c

In barrier.c at Chap 31(31/barrier.c), you use two variable in barrier_t, but I think you can just keep num_threads and use num_threads--; when a thread enter barrier, then test num_threads==0 . Besides, in fact test of num_threads is not in critical section, so you can put Sem_post(b->modCounter); before the test.

small bug that exists in main-common.c of hw 30

In hw 30, if I use command ./main-one-cv-while -c 2 -p 1 -l 1 -P 0,0,0,0,0,0,2 -v which let two consumers sleep, then the whole program will crash. After some debug, I found a problem with the following code in main-common.c:

for (i = 0; i < consumers; i++) {
    Mutex_lock(&m);
    while (num_full == max) 
        Cond_wait(empty_cv, &m);
    do_fill(END_OF_STREAM);
    do_eos();
    Cond_signal(fill_cv);
    Mutex_unlock(&m);
}

when the producer is finished, END_OF_STREAM will be written into buffer and one of consumers will wake up. However, I found that it is not as I expected. It seems like that one of consumers will be set to ready state and the for loop will release the lock but immediately acquire the lock again. because num_full equals max at this time so the for loop will sleep. then one of consumers will execute and finally wake up one thread between the other consumer and the for loop. however, it will choose the other consumer rather than the for loop. so END_OF_STREAM will not be written into buffer again and cause the whole program to crash. If I change the code to the following, then there is no problem.

for (i = 0; i < consumers; i++) {
    sleep(1);
    Mutex_lock(&m);
    while (num_full == max) 
        Cond_wait(empty_cv, &m);
    do_fill(END_OF_STREAM);
    do_eos();
    Cond_signal(fill_cv);
    Mutex_unlock(&m);
}

I wonder whether this problem is OS-dependent or just a bug? Thanks a lot!

chapter 5 Q 2

If you write open() before fork(), as indicated in the question, both processes will append to the end of th file, not overwrite.

Does chapter 8, question 5, have an incorrect answer?

First, I just want to say thanks for sharing your solutions 🎉 This is a great resources as I'm working through these exercises.

On chapter 8, question 5, we have the following question:

Given a system with a quantum length of 10ms in its highest queue, how often would you have to boost jobs back to the highest priority level (with the -B flag) in order to guarantee that a single long-running (and potentially-starving) job gets at least 5% of the CPU?

And it looks like your answer is 50ms, but shouldn't it be 200ms? It seems like 10ms will have to be 5% of the boost period.

So given a boost period B, I thought the equation would look like this:

B * .05 = 10 ms

which makes B 200ms.

But maybe my answer is missing something? Perhaps there's an edge case where the 200ms boost period fails, but I can't think of one 🤔

Does Chapter 05 Homework 3.c have a bug?

English is not my native language; please excuse typing errors.

First, I want to thank you for this amazing repo which helps me a lot.

In Chapter 5 Homework 3.c

....
else if (rc == 0) {
    kill(parent_pid, SIGCONT);
    printf("hello\n");
}
....

We send a signal to the parent process, then we use printf.
I think if the OS decides to switch to the parent process after kill but before printf, the screen will show goodbye first.
So I think you should put printf before kill.

I run your code on Ubuntu 16.04.7 LTS, gcc version is 5.4.0 20160609, it sometimes prints hello first, sometimes prints goodbye first.

Question 4/6

Hello Sir,

Sir I am currently learning OS in college and while I was doing this homework I stumbled upon the difference between question 4 and 6 (Chapter 30 / conditional variables)

I don't understand why having a sleep at c3 is different than having it at c6. In both cases the lock is released.

I would really appreciate if you can provide me with some explanation.

Regards

Error in question6's answer of Chapter 37

I think skew should be calculate as follow:
skew = (rotation-speed*track-distance(40)) / seek-speed / rotational-space-degrees(360 / 12)