每个tick实体运行run处理deferred表中和evbuf中的事件(处理future表时添加),都会处理一下future表中的事件(add实体时添加CREATE事件,实体start时添加SEND事件,futue处理CREATE事件时添加SEND事件)。总之,实体是事件执行的载体,事件是实体的目的。
实体的派生类包括ContainerDatacenterBroker,ContainerDatacenter,CloudSimShutdown,此外还有Switch,GlobalBroker。事件没有派生类。
下面就从实体入手追踪cloudlet的执行过程。
打开ContainerDatacenterBroker,找到processEvent,这里面有可能有关于cloudlet执行的东西,发现有一个CLOUDLET_RETURN。
打开ContainerDatacenter,找到processEvent,发现有CLOUDLET_SUBMIT,CLOUDLET_CANCEL,CLOUDLET_PAUSE,CLOUDLET_RESUME,CLOUDLET_REMOVE,CLOUDLET_STATUS,包括ACK。原来datacenter是执行cloudlet的初始载体。
一、cloudlet在什么时候由谁提交?
继续追踪事件的来源,发现CLOUDLET_SUBMIT事件来自ContainerDatacenterBroker的CONTAINER_CREATE_ACK事件
,继续发现来自ContainerDatacenter的CONTAINER_SUBMIT事件。即ContainerDatacenter的CLOUDLET_SUBMIT事件由ContainerDatacenter的CONTAINER_SUBMIT事件触发。
继续追踪事件的来源,发现ContainerDatacenter的CONTAINER_SUBMIT事件来自ContainerDatacenter的VM_CREATE_ACK事件,继续发现来自ContainerDatacenter的VM_CREATE事件(ACK)或VM_MIGRATE事件(ACK)和ContainerDatacenterBroker的CLOUDLET_RETURN事件或RESOURCE_CHARACTERISTICS事件。其中需要关心的VM_CREATE_ACK事件来自ContainerDatacenterBroker的RESOURCE_CHARACTERISTICS事件,又来自ContainerDatacenterBroker的RESOURCE_CHARACTERISTICS_REQUEST事件。
继续追踪事件的来源,发现这个事件来自ContainerDatacenterBroker的startEntity()。原来cloudlet在runstart的时候由ContainerDatacenterBroker提交。
二、cloudlet在什么时候由谁执行?
继续往里看CLOUDSUBMIT事件的
三、ContainerCloudlet的表示问题
它是由
int cloudletId, long cloudletLength, int pesNumber, long cloudletFileSize, long cloudletOutputSize, UtilizationModel utilizationModelCpu, UtilizationModel utilizationModelRam, UtilizationModel utilizationModelBw, boolean record, List<String> fileList
这些东西来表示一个cloudlet的。
即需要知道Length,pesNumber,FileSize,OutputSize,CPU、RAM和BW的utilizationModel,是否记录历史,需要哪些文件(没有实际用过)。