INE5357 - Operating Systems II - 2006/2

Group 1

E1: thread joining

Introduction

Solution

After some analysis we discovered in traits.h a property related to this feature. We decide to adopt it to our solution, since it keep our design coherent with the remaining of the system. So ``Traits<Thread>::busy_waiting'' was adopted.

After that we search for the entry point for Thread::join(). Here we put a conditional making the original behavior be splitted in two ways, with and without busy waiting. With busy waiting it remains the same, but without it goes to Thread::wait().

When some thread (t1) call the Thread::wait() of the other (t2), t1 is suspended until some event occurs to t2. Actually, just before destruction and on exit of t2, the first a safe guard and the second necessary to our exercise. When one of those events occurs Thread::notify() is called.

Thread::wait() and Thread::notify() make the tricks needed, but not without some structural changes in Thread. First we need a collection of some sort to hold some other Threads, Thread::Queue is there and is of correct type so it is used, since the need of search is almost zero it fits ideally also. And then Thread::_waiting was born, it is a private instance member attribute for Thread.

Second a reference (pointer) to other Thread. This is needed in case we want to destroy (clean up) this thread and it is waiting the signal of this other thread.

After Thoughts

These structural changes causes some memory overhead when busy_waiting is required since at least one pointer (_awaker) and one class (_waiting) stay useless. There are strategies already planned to solve it but it is so off the topic of the subject that we will not describe here.

The option of use a semaphore to control the execution was discarded on the moment of identification of circular dependency between already implemented Thread and Semaphore.

We wanted to deliver some fancy drawings explaining the process but we are too lazy to do that.

Table of Files