Алекс Jenter - Программирование на Visual C++. Архив рассылки

// постановка хука...

g_hHook = SetWindowsHookEx(WH_MSGFILTER, HookProc,

GetModuleHandle(NULL), GetCurrentThreadId());

break;

case WM_COMMAND:

switch(LOWORD(wParam)) {

case IDCANCEL:

if (BN_CLICKED == HIWORD(wParam)) {

// ... и его снятие

if (g_hHook) UnhookWindowsHookEx(h_hHook);

EndDialog(hDlg, 0);

}

break;

}

break;

}

return 0;

}

Теперь обратимся к процедуре. Легко заметить, что она выполняет практически те же действия, что и из ОСНОВНОГО ВАРИАНТА, а именно – обнаружение нажатия Enter и переход на следующий контрол, имеющий стиль. Поскольку нас интересуют только события диалогов (а не меню, и не скроллбаров), то и фильтровать мы будем только коды типа.

LRESULT DlgBoxMsgFilter(UINT code, WPARAM wParam, LPARAM lParam) {

LPMSG pMsg = (LPMSG)lParam;

HWND hEdit1 = GetDlgItem(g_hDlg, IDC_EDIT1), hEdit2 = GetDlgItem(g_hDlg, IDC_EDIT2);

switch (code) {

case MSGF_DIALOGBOX:

{

// следим за нажатиями в обоих эдитбоксах

if (hEdit1 != pMsg->hwnd && hEdit2 != pMsg->hwnd) return -1;

switch (pMsg->message) {

case WM_KEYDOWN:

if (VK_RETURN == pMsg->wParam) {

// нажат Enter, сообщим об этом родительскому окну (диалогу)

SendMessage(g_hDlg, pMsg->message, pMsg->wParam, pMsg->lParam);

// перейдем к следующему TABSTOP-контролу диалога

SetFocus(GetNextDlgTabItem(g_hDlg, pMsg->hwnd, FALSE));

return TRUE;

}

break;

}

}

break;

}

return –1;

}

На этом, собственно, мы и остановимся. Насколько понятно/удобно/оправдано пользоваться этим методом – судить вам.

ПРИМЕЧАНИЕ

В демонстрационном проектевы найдете подпроект HkEdDlg, в котором продемонстрирована приведенная методика. Там же, кстати, вы сможете найти и пример реализации глобального (системного) хука, но это, как говорится, уже совсем другая история…

Это все на сегодня. Пока!

Здравствуйте, уважаемые подписчики!

Довольно давно я прочитал статью, автор которой объединил две концепции – многозадачность и объектно-ориентированное программирование. В результате получились так называемые "живые объекты". Идея крайне проста – при инициализации объекта создается отдельный поток и объект в нем живет своей жизнью, а создатель объекта по мере необходимости получает информацию о состоянии объекта из его свойств. Код для такого объекта на C++ выглядит примерно так:

class living_object {

...

static DWORD threadHelper(LPVOID);

void run();

public:

bool animate();

...

};

bool living_object::animate() {

...

CreateThread(NULL, 0, ThreadHelper, (LPVOID)this, 0, &threadID);

...

}

DWORD living_object::threadHelper(LPVOID instance) {

((living_object*)instance)->run();

}

void living_object::run() {

while(true) {

...

Sleep(...);

}

}

"Живые объекты" позволяют отказаться от необходимости делить внутреннюю логику объектов, работающих параллельно, на куски, которые создатель объектов должен сам вызывать в определенной последовательности, фактически беря на себя функции диспетчера потоков.

Конечно же нельзя забывать о том, что "живые объекты" привносят в программу проблемы синхронизации доступа к свойствам объекта. Особенно это относится к сложным типам данных наподобие std::vector. Однако было бы ошибкой думать, что базовые типы данных не нуждаются в синхронизации доступа к ним. Хотя на массово распространенных сейчас однопроцессорных системах подобное пренебрежение синхронизацией может не вызывать проблем, но на многопроцессорных системах последствия могут быть самыми неожиданными. Так что лучше не уподобляться тем программистам, которые были уверены, что их программы к 2000-му году уже не будут использоваться.

Одновременное выполнение нескольких потоков только кажется параллельным. На самом деле количество потоков, работающих параллельно, прямо зависит от количества процессоров. Само собой, что на однопроцессорной системе в каждый момент времени работает только один поток. Процессорное время распределяется между потоками диспетчером потоков операционной системы. Конечно же переключение между потоками, так же называемое переключением контекста процессора, не бесплатно с точки зрения процессорного времени. Это связано с тем, что контекст процессора включает в себя некоторое количество информации, например состояние регистров процессора, а перемещение любого количества информации отнимает процессорное время.

Что же вызывает переключение контекста? Вариантов всего два – или поток отдает управление операционной системе добровольно, посредством вызова одной из соответствующих функций, или операционная система сама отбирает управление у потока по истечении минимального разумного времени, называемого time slice.

Теперь перечислю собственно вопросы, побудившие меня провести ряд экспериментов, и, в конечном итоге, написать эту заметку.

1. Каковы издержки на явное переключение контекста? Как они зависят от количества потоков в программе?

2. Как влияет на производительность многопоточной программы наличие в системе дополнительного процессора?

3. Как зависит производительность многопоточной программы от конкретной операционной системы?

4. Какие существуют ограничения на количество потоков в программе?

Сразу хочу оговориться, что тестовая программа имитирует систему, активно использующую "живые объекты", описанные в начале заметки. Это связано с тем, что меня интересовали вышеперечисленные вопросы применительно именно к "живым объектам". Для многопоточных программ с другой логикой организации работы потоков результаты испытаний могут быть другие. Так же прошу принять во внимание, что замеры не проводились с лабораторной тщательностью, и поэтому нужно сделать скидку на определенную погрешность в цифрах. Для компиляции использовался Visual C++ 6 SP5.

Тестовая программа создает заданное количество "живых объектов", которые все вместе выполняют фиксированный объем вычислений, и замеряет общее время выполнения. Вычисления выглядят следующим образом – в цикле вызывается библиотечная функция rand(), результат которой делится по модулю на некоторое число. Каждый "живой объект" выполняет количество итераций цикла равное общему количеству итераций, заданному для всей программы, поделенному на количество "живых объектов".