Comments on project 1

Overall, the projects were well done. Everybody wrote an essentially correct queue implementation and semaphore implementation. The real differences turned out to be in how the minithreads operations were implemented: the best grades went to groups which dealt with the NT kernel thread effectively, reused code (e.g. minithread_fork can call minithread_create), and had a clear and efficient mechanism for cleaning up threads. The best thread-cleanup schemes involved a "cleanup" thread waiting on a semaphore and being signalled by terminating threads, or a check for threads on the cleanup queue whenever a thread came out of a minithread_yield(). Terminating the application once once all the application-created minithreads have terminated also earned a bonus to the grade.

Common problems included:

• Using a full minithread_create to make a TCB for the NT kernel thread: this is unnecessary, since it creates a stack for the NT thread as well as the TCB. When a context switch occurs "away from" the NT thread (e.g. it calls minithread_yield), the TCB stack top pointer is overwritten with the pointer to the top of the NT thread's stack. As a result, the stack allocated by the minithread_create is lost (a memory leak). A "stripped-down" version of minithread_create, with no stack creation, avoided this problem.
• A "ready queue" which stores more than just threads in the ready state: either storing the running thread at the head of the ready queue, or waiting threads as well. Storing the running thread at the head makes detecting when the queue is "empty" a little more complicated. There is not much point in storing waiting threads in the queue, since it just complicates the scheduler (and some implementations could result in an infinite loop in the scheduler).
• A wait queue is unnecessary, queues in the individual semaphores are enough. Having a wait queue would only be useful if there was some operation which required traversing all the waiting processes. Typically, in real OSes, threads are blocked on a queue associated with the resource they are waiting for, rather than a general waiting queue.
• Context-switching regardless of whether the new thread and old thread are distinct or not! It is a wasted operation to switch from a thread to itself. A ready queue design which incorporated waiting threads made this harder to spot.
• Stopping the NT kernel thread after forking the first minithread. Since you already have the NT kernel thread, which you can turn into a minithread by allocating a TCB, why not use it to run system code (e.g. idle thread or cleanup thread)?
• Unnecessary special-case code (e.g. calling minithread_switch directly to start the first minithread, rather than minithread_yield or minithread_stop to transfer control from the NT kernel thread).

Ben Atkin