Allow child CloudletSchedulerTimeShared classes to apply a preemption mechanism to perform context switch between Cloudlets sharing the same PEs

[manoelcampos]

IMPROVEMENT

The current CloudletSchedulerTimeShared class (inherited from CloudSim) provides an oversimplified time-shared scheduler which considers that every submitted Cloudlet will be immediately added to the execution list, even if the number of Cloudlets is greater than the number of existing PEs.

This is an oversimplification inherited from CloudSim that has a minor effect in how Cloudlets are executed, considering that context switch overhead is not concerned and would be challenging to implement.

The current CloudletSchedulerTimeShared implementation makes all submitted Cloudlets to be executed simultaneously, regardless of the number of PEs. By this way, if there is 1 PE of 1000 MIPS and 2 Cloudlets requiring 1 PE each one, all these 2 Cloudlets will run at the same time. However, each PE will be used simultaneously by 2 Cloudlets, splitting the PE capacity between them. That gives 500 MIPS for each Cloudlet to use. By this way, the scheduler always adds Cloudlets to the execution list and the waiting list is always empty.

In a real computer, it is not possible to run 2 processes in the same processor CORE at the same time by just splitting the core capacity between the processes. A CPU core can only be used by a single process at a given time. The oversimplification given by the CloudletSchedulerTimeShared hasn't a great impact on the simulation. Just the results are a little bit different if it was used a more realistic approach. Considering that all 2 Cloudlets in the given example have 10000 MI of length, this implementation makes that all these Cloudlets finish at the same time in the 10th simulation second.

However, in a real time-shared scheduler that does not assign priorities to process and gives the same time slice to every process, a Cloudlet will, in fact, finish prior to another one. As depicted below, the Cloudlet 0 will finish in the 4th second, while Cloudlet 1 will finish just in the 5th second:

Time in seconds	00 01 02 03 04 05
Running Cloudlet	C0 C1 C0 C1 C0 C1

The issue is that if one needs to implement a new and more realistic time-shared CloudletScheduler such as the Completely Fair Scheduler used in the Linux Kernel, this behaviour in the CloudletSchedulerTimeShared will not allow the implementation of a subclass defining a different behaviour.

Detailed information about how the feature should work

Refactoring in the CloudletSchedulerTimeShared and superclass should be made to allow the scheduler implementation to define when a submitted Cloudlet has to go to the waiting list, according to scheduler policies.

An example scenario where this feature should be used

This enhancement will enable the implementation of more realistic schedulers such as the Completely Fair Scheduler already mentioned, that preempts executing tasks in order to give other Cloudlets the opportunity to run.

A brief explanation of why you think this feature is useful

The CloudletSchedulerTimeShared scheduler is quite naive and a more realistic one would enable simulation of more complex and useful scenarios.