Билет №19
1. Сведение планирования к задаче целочисленного линейного программирования
Пусть N={1,…n} - множество планируемых операций.
Бинарное отношение H непосредственного предшествования операций (если (i,j)H, то i непосредственно предшествует j) строится в результате анализа информационных зависимостей между операциями
Отношение H представляется конечным ориентированным графом GH.
Минимальный шаг Si выполнения операции i определяется по плану, генерируемому ASAP.
Максимальный шаг Li выполнения операции i определяется по плану, генерируемому ALAP.
Число используемых в плане процессоров типа k есть bk при k=1,…,TYPES.
Стоимость процессора типа k определяется величиной сk.
Обозначим через xij двоичную переменную, принимающую значение 1 в случае, если операция i выполняется на шаге j, и принимающую значение 0 в случае, если операция i не выполняется на шаге j.
Рассмотрим задачу построения обыкновенного плана, имеющего минимальную стоимость при заданном числе Т шагов управления (time-constrained scheduling). Стоимость выразим суммарной стоимостью используемых планом процессоров всех типов.
Эта задача формулируется в виде следующей задачи целочисленного линейного программирования:
Целевая функция:
Система ограничений:
при
1jT,
1kTYPES,
при
1in,
при
(i,j)H.
Ограничение (1) вытекает из того факта, что на каждом шаге число используемых процессоров типа k не должно превышать число bk имеющихся процессоров этого типа.
Ограничение (2) выражает возможность выполнения любой операции ровно на одном шаге управления (обыкновенное планирование).
Ограничение (3) формализует тот факт, что операция j должна выполняться на шаге с номером большим, чем номер шага, на котором выполняется операция i, в случае, если операция i предшествует операции j.
Для рассмотренного ранее графа предшествования операций и числа шагов управления T=5 планы ASAP и ALAP имеют вид, представленный на рис.1.
Рис. 1. Планы ASAP и ALAP, построенные на 5 шагах управления
Значения величин Si и Li при i=1,…,n определяются следующей таблицей:
Тип процессора |
type1 |
type2 |
||||||
Операция |
1 |
3 |
5 |
6 |
8 |
2 |
4 |
7 |
Si |
1 |
1 |
3 |
1 |
4 |
2 |
2 |
2 |
Li |
2 |
2 |
4 |
3 |
5 |
3 |
3 |
4 |
2. Запрос интерфейса. Интерфейс iUnknown. Реализация интерфейса
Клиент всегда взаимодействует с компонентом через некоторый интерфейс. Даже для запроса интерфейса у компонента клиент использует специальный интерфейс IUnknown. Определение IUnknown, содержащееся в заголовочном файле unknwn.h, входящем в состав Win32 SDK, выглядит так:
interface IUnknown {
virtual HRESULT __stdcall QueryInterface(const IID& iid, void** ppv) = 0;
virtual ULONG __stdcall AddRef() = 0;
virtual ULONG __stdcall Release() = 0;
}
Поскольку все интерфейсы СОМ наследуют IUnknown, в каждом интерфейсе есть функции QueryInterface, AddRef и Release —первые три функции в vtbl:
interface IType_1 : IUnknown { virtual void __stdcall operT1(int, int, int*) = 0; };
Все интерфейсы СОМ можно полиморфно трактовать как интерфейсы IUnknown. Поскольку все указатели интерфейсов являются также и указателями на IUnknown, клиенту не требуется хранить отдельный указатель на компонент. Клиент работает только с указателями на интерфейсы. Для получения указателя на IUnknown используется вместо оператора new функция
IUnknown* CreateInstance();
Она создает компонент и возвращает указатель на IUnknown
В IUnknown имеется функция с именем QueryInterface. Клиент вызывает ее, чтобы определить, поддерживает ли компонент некоторый интерфейс. QueryInterface возвращает указатель на интерфейс, если компонент его поддерживает; в противном случае возвращает код ошибки. У QueryInterface два параметра:
Virtual HRESULT __stdcall QueryInterface(const IID& iid, void** ppv);
Первый параметр — идентификатор интерфейса. Второй параметр — адрес, по которому QueryInterface помещает указатель на искомый интерфейс. QueryInterface возвращает HRESULT; это не описатель handle,. это —32-разрядный код результата, записанный в определенном формате. QueryInterface может возвратить либо S_OK, либо E_NOINTERFACE. Клиент не должен прямо сравнивать возвращаемое значение с этими константами; для проверки надо использовать макросы SUCCEEDED или FAILED.
Пример реализация функции QueryInterface:
HRESULT __stdcall COMP::QueryInterface(const IID& iid, void** ppv) {
if (iid == IID_IUnknown) {
*ppv = static_cast<IType_1*>(this);
} else if (iid == IID_IType_1) {
*ppv = static_cast<IType_1*>(this);
} ... else {
*ppv = NULL;
return E_NOINTERFACE;
}
reinterpret_cast<IUnknown*>(*ppv)->AddRef();
return S_OK;
}
Пример использования функции QueryInterface:
void main() {
HRESULT hr;
IUnknown* pIUnknown = CreateInstance();
IType_1* pIType_1 = NULL;
hr = pIUnknown->QueryInterface(IID_IType_1, (void**)&pIType_1);
if (SUCCEEDED(hr)) {
cout<<s_conv("Клиент: IType_1 получен успешно")<<endl;
} else return;
...
}
Задача - Привести пример цепочечного плана
Цепочечное планирование на базе ASAP
Тип – планирование на достижимость.
Исходные данные:
Граф непосредственного предшествования операций.
Времена t(i), iN выполнения операций.
Время tstep шага управления.
Результирующие данные:
Шаги управления.
Распределение операций по шагам управления.
Число процессоров каждого типа.
Граф по которому планируем:
Рис. 4. Цепочечное планирование ASAP; t(1)= t(3)= t(5)= t(6)= t(8)=1; t(2)= t(4)= t(7)=2; tstep=2; общее время решения задачи 6 единиц (при простом планировании 8 единиц)