Posted on by

CS2106 Midterm 2010/11 Semester 1

Here is the Midterm Test Paper from last academic year.

No solution will be posted. Please discuss your solution here.

Note: you did not use the strace command this semester; it is used to trace system calls made when running an executable.

44 thoughts on “CS2106 Midterm 2010/11 Semester 1”

      • i sincerely suspect the answer is hardware interrupt because you need a spinlock to control that…..

        but please prof… give us some hints XD

          • i read that for hardware interruption, there might be cases that one CPU take over the process from another process. and the guy mentioned that in this case, something called a spin lock is required.
            i do not really understand what that is, so after a while i gave up :D
            but anyway, since i think A context switch B system call may happen and C software interrupt sounds pretty normal … i suppose the answer is D….

            • You shouldn’t answer MCQs through process of elimination, since it is possible that all choices are incorrect!

              A spinlock refers to a loop that checks if the lock has been released:

              while (lock);

              I do not understand the part where you said “one CPU takes over the process from another process”

                • I see.. I can’t comment much on multiple CPU cases without reading the original article as it is not obvious to me how spinlock is involved here.

  2. For question 13(a), i felt that the value of x will always be 0. However, question 13(b) make me slightly doubt my answer.

    Hence, i tested the code on my Ubuntu and run the program using a for loop, and check the program to print the output if x!=0. After letting it run about 5 min, no number has been displayed.

    What do you think is the answer?
    a) 0
    b) -5 <= x <= 5
    c) none of the above

    • Since it loops 5 times only, the chances of having a race condition and non-zero answer is low (but still can happen). Try to increase the number of loops to, say, 50000, and see what happen.

  3. In a priority scheduling situation, does a process with higher priority need to wait for a process with lower priority to run finish its time quatum? Or can a higher priority process preempt the lower priority process immediately without waiting for the time quantum to run out?

    • Either case can happen. Depending on the scheduling algorithm. For really high priority process (such as kernel-related or critical process) it makes sense to let it preempt a lower priority one.

  4. For MCQ Q7 I feel that only C is possible??

    A: Will be stuck waiting after R since the signal is already sent
    B: Cannot get to S before P
    D: Signal will be sent after P, however mutex is still locked by thread 1 so thread 2 will block on return of wait, therefore Q must execute before S.

    • Yes, I believe I meant to ask “which is possible” instead of “NOT possible”. So we end up with 3 possible answers (but in the test you should only write one)

    • Pointer x point to new object, while pointer y point to pointer x.

      During *y=0, the value pointed by pointer y (which is pointer x) is change to 0. Thus, pointer x is now pointing to address 0

      During *x=1, the program is attempting to assign value 1 to memory address 0, which result in segmentation fault, since it is not able to access memory address 0.

      Hope this help.

  6. If it makes more sense, in the midterm last question, we can safely assume B can interrupt A when A only run for 0.5 unit time?


    Ooi Wei Tsang:

    Either case can happen. Depending on the scheduling algorithm. For really high priority process (such as kernel-related or critical process) it makes sense to let it preempt a lower priority one.

    • It makes more sense only if the preempting process is really important (such as kernel or a process that steer a rocket), otherwise, it would leads to more context switches and thus more overhead.

      For the last midterm question from last year, the question specifically says that “The CPU schedules the next process as soon as the current process blocks for I/O, is preempted, or exits.”

      No mention that scheduling is done when a process completes its I/O.

      • “The CPU schedules the next process as soon as the current process blocks for I/O, is preempted, or exits.”

        For this question, do we allow the preemption of lower priority processes by higher priority processes?

        • No. The question says that the scheduler only schedules the next process when three things happen: (i) the current process blocks for I/O; (ii) the current process is preempted; (iii) the current process exits.

      • Hi Professor, although the question does not specify whether the scheduler preempts after a process completes I/O, can we assume that the process C is a very important process? Or both ways of scheduling are allowed?

        Thanks!

        • This question leave up with many possible answers, depending on how the scheduler preempt the processes.

        • The question DID specify when scheduling happens.

          If the statement “The CPU schedules the next process as soon as the current process blocks for I/O, is preempted, or exits.” is missing, then yes, you can make any reasonable assumption.

    • Assuming scheduler reschedules process as soon as the highest priority is ready to run and assuming I/O can be done simultaneously, then i got 15.

      • Assuming that the scheduler have to wait for low priority process to run finish its quantum time, i got 14.5 for (b)

        Assuming if high priority process can preempt low priority process right away, i got 15.

  8. But it says in the question: The CPU schedules the next process as soon as the current process blocks for I/O, is preempted, or exits. We ignore the time taken for context switching.

    first would be when it’s time to do i/o, second would be when the 1 unit time quantum is finished, and third one would be when the process finishes and exits. Why did you guys consider that it also reschedules process as soon as the highest priority is ready ?

    • Out of the 3 possible answers i have seen, i do not agree 12 unit time as the answer.

      I assume that the reason why you get 12 unit time because you preempt the process immediately after its run out of its quantum time.

      To prove why this is not the correct answer, let look at similar question, question 1 in tutorial 5. Does process A (higher priority) give up its CPU to process B (lower priority) after the quantum time is over? If it does, will the answer be tally with the final answer provided on the second page?

        • hmm ok i made a mistake in my previous trace… now i have 14 as my answer. still don’t see how to get 14.5 or 15.. my process trace(each alphabet represents 0.5 time units):

          |CB|BB|BC|BB|BB|CB|AA|CB|BB|CA|AA|AC|AA|AA|CX

          • |CB|BB|BC|

            During the 4th 0.5 time unit of B, C is in ready state and B has used up its time quantum (1 time unit). Scheduler can preempt C to run CPU right away, hence B only run for 1.5 unit time.

            • how can C preempt B in the middle of B’s time quantum? i thought B will be allowed to finish 1 unit of time quantum before scheduling happens.. so unless it is a voluntary block or exit, each process will run in full length of the 1 unit time quantum it is given?

              |CB|BB|BC|

              so here my 2nd and 3rd 0.5 time unit of B is 1 time quantum, and the 4th and 5th B is 1 time quantum.

              did i just misunderstood how the time quantum works ._.

              • Priscilla is right — as mentioned many times in the comments, in the context of this question, high priority process does not preempt lower priority one as soon as its I/O completes, it has to wait for the lower priority process to finish its time quantum first.

    • I do not know which one is the right answer.

      For 14.5 (each alphabet represent 0.5 time units):
      |CB|BB|CB|BB|CB|BB|CA|AB|BC|BA|AC|AA|AC|AA|A

      For 15:
      |CB|BB|CB|BB|CB|BB|CA|BB|CB|AA|CA|AA|CA|AA|CA|

Comments are closed.