Assignment 6: Events and Synchronization

It is time to extend your StuBS with synchronization objects, enabling threads to inform each other about different events or to wait for them.

Create the following synchronization objects:

• Semaphore to synchronize application threads with each other. Use them for example to block an application thread after it has queried the keyboard for (yet non-existent) input until a key is pressed.
• Bell to put threads to sleep for a certain period of time.

Create a Waitingroom (containing Threads waiting for events) and the Bellringer (efficiently checking for Bells to activate) for this purpose. You'll have to modify Scheduler, Thread, Keyboard and Watch and create the system call wrappers GuardedBell, GuardedSemaphore and GuardedKeyboard.

To cut power usage, a core should sleep (using the hlt instruction) if no threads are waiting for their execution. Since only interrupt handling routines will activate threads, the execution should be continued if there are new threads in the ready list after an interrupt.

You can achieve this behaviour by introducing idle threads (exclusively dedicated to each core). They are scheduled as soon as there are no threads in the ready queue and perform the idle loop.

For MPStuBS, it is necessary to wake up sleeping cores whenever a thread is put back on the ready list (by calling Scheduler::ready()). Use a separate IPI triggering a WakeUp (similar to Scheduler::kill(Thread *that) and the Assassin).

Map of important classes for the sixth assignment

Learning Objectives

• Synchronization using semaphores and other core objects

Videos (in German)

 

• Gegenseitiger Ausschluss (7 min)
• Zeitgesteuertes Warten (5 min)
• Aufgabe 6 (8 min)

Implementation Notes

We recommend the following order to allow good separate testing of the individual parts.

Semaphore Implementation

It is best to start with Waitingroom and Semaphores. Using semaphore variables, you should be able to prevent your application threads from interfering with each other during screen output.

Blocking Keyboard Input

In the next step, you can extend the Keyboard with the getKey() method. The method uses a Semaphore to block threads if there is no Key to retrieve present. Extend your Application in such a way that one thread queries the Keyboard (and prints its result).

Time Events using the Bell

Afterwards, you can start working on Bellringer. Check the correct behaviour of all possible cases: insertion at the front, back, somewhere halfway between, empty list, etc. Watch should frequently make calls to the global Bellringer instance's Bellringer::check() method. Having the Bell (or rather GuardedBell), it is quite easy to create periodic threads, letting them sleep for a few milliseconds and then perform an action (e.g., make an output). Demonstrate this with a suitable example (multiple threads that wake up at different intervals).

Idle Thread

It is finally time to address the idle core problem. Have a look at Core::idle(). Include test scenarios in your example application with too few (in MPStuBS) or no threads available for execution.

Tickless Kernel (Voluntary)

Once you have solved the idle problem, you can then proceed to enhance your implementation in such a way that the timer does not constantly interrupt idle cores. This is desirable to reduce power consumption. Add the ability to block and unblock the Watch in the IdleThread.

Note

Obviously, you should only switch off all cores if there is no Bell pending in the Bellringer's queue.

PC Speaker (Voluntary)

The beeping PC speaker is a historical relic that is sometimes still present in modern systems (like our test boxes). The speaker is connected to the PIT and can produce a tone at the frequency of your choice. PIT::pcspeaker() provides you with an interface to set the desired frequency (preferably with interrupts disabled). The speakers should then skril accordingly, until you change it or silence the device with a frequency of 0.

That makes it a perfect demonstration application for passive waiting: A thread sets a frequency and then goes to sleep for a given time before switching to the next frequency.

#include "machine/pit.h"
#include "machine/core.h"
#include "syscall/guarded_bell.h"
 
// ...
 
static const int melody[][2] = {
    {659, 120}, {622, 120}, {659, 120}, {622, 120}, {659, 120}, {494, 120},
    {587, 120}, {523, 120}, {440, 120}, {262, 120}, {330, 120}, {440, 120},
    {494, 120}, {330, 120}, {415, 120}, {494, 120}, {523, 120}, {330, 120},
    {659, 120}, {622, 120}, {659, 120}, {622, 120}, {659, 120}, {494, 120},
    {587, 120}, {523, 120}, {440, 120}, {262, 120}, {330, 120}, {440, 120},
    {494, 120}, {330, 120}, {523, 120}, {494, 120}, {440, 120}, {0, 10}
};
 
kout << static_cast<char>(14) << flush;
for (auto tone : melody) {
    GuardedBell bell;
    Core::Interrupt::disable();
    PIT::pcspeaker(tone[0]);
    COre::Interrupt::enable();
    bell.sleep(tone[1]);
}
kout << "." << endl;

Note

Actually, the PIT is comparatively easy to handle, the difficulty here lies rather in the test environment: In the CIP, Qemu/KVM will remain silent. A remedy is the (rather poorly documented) environment variable QEMU_AUDIO_DRV – try starting with QEMU_AUDIO_DRV=alsa make kvm