Master - Slave

As is usually the case in Parallel Computing, we presumed that communication is much slower than computation when designing our parallel solution to collision detection. This assumption implies performing as little communication as possible to make sure that all processors in the computer are kept busy and no time is wasted. An easy strategy to obtain this goal is using a Master Slave approach, shown in 3. In this approach, we start up a task that divides the total work and assigns it to a number of worker tasks.

  

Figure 3: Master Slave approach

The controlling task is called the master, the tasks doing the actual work are called slaves. Usually, slaves are generated as necessary to solve the problem, leaving it up to PVM when and where to execute them. This is not the approach we'll be taking for a number of reasons. First of all, generating a lot more processes than there are processors available can induce a lot of overhead since this will cause several tasks to be multiplexed over a single processor. The second reason is inherent to the collision detection problem itself, namely the initialization time. Each time a new slave is started, it will have to load the entire scene into its memory. As this is probably the most expensive part in the entire program, requiring a lot of disk access and list traversal, this will incur a great loss of speed. That's why we keep the slaves alive during the entire run of the program, so that they can load the scene once and use it over and over again. Of course, due to this approach, we need to provide an explicit communication protocol instead of passing all the needed data before starting up. Now, let's look at the Master's responsibilities a bit closer.