есть такая такая ситуация — постоянно приходят запросы, рабочий поток их обрабатывает
организована схема с одним потоком, это выгладит примерно так:
#define COPY_QUEUE_TO_LOCAL_VAR(__var, __pClass) \
do { \
::WaitForSingleObject((__pClass)->m_hMutex, INFINITE); \
__var = *(__pClass)->m_pContainer; \
(__pClass)->m_pContainer->clear(); \
::ReleaseMutex((__pClass)->m_hMutex); \
} while (0)
DWORD ThreadWorker::Run(LPVOID param)
{
CXtraScript* pClass = reinterpret_cast<CXtraScript*>(param);
while(TRUE)
{
WaitForSingleObject(pClass->m_hEvent, INFINITE);
// typedef std::deque<boost::shared_ptr<MemberInformation> > typed_container;
// очередь запросов
CXtraScript::typed_container c;
// скопировать всю очередь в локальную переменную
// заодно очистить очередь
COPY_QUEUE_TO_LOCAL_VAR(c, pClass);
do
{
for(CXtraScript::typed_container::iterator it = c.begin(); it != c.end(); it++)
{
// делаем что-то продолжительное
Sleep(5000);
}
// проверяем, поступление новых запросов
// во время обработки
COPY_QUEUE_TO_LOCAL_VAR(c, pClass);
} while(c.size());
}
return (0);
}
хотел переписать код с использованием новых функций win2000
не понял как работает QueueUserWorkItem()
вот набросал тест:
#define STRICT
#define _WIN32_WINNT 0x0500
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <tchar.h>
#include <strsafe.h>
HANDLE hCon;
DWORD WINAPI ThredaProc(LPVOID lpParameter)
{
const UINT cbSize = 512;
TCHAR szBuffer[cbSize+1];
size_t length;
DWORD written;
StringCchPrintf(szBuffer, cbSize, _T("ThreadProc(%d)\n"), (UINT) lpParameter);
StringCchLength(szBuffer, cbSize, &length);
WriteConsole(hCon, szBuffer, length, &written, NULL);
Sleep(1000); // иммитация задержки
return (0L);
}
int main()
{
hCon = GetStdHandle(STD_OUTPUT_HANDLE);
for(int i = 0; i < 10; i++)
{
QueueUserWorkItem(ThredaProc, (LPVOID) i, WT_EXECUTEDEFAULT/*WT_EXECUTEINIOTHREAD*/);
}
return (0);
}
а выводится только ThreadProc(0)
я чего-то не понимаю или где?
Sleep(1000) — эта строчка не понравилась. Нехорошо наверное тормозить рабочий поток надолго. Система может "заподозрить" неладное и прибить его например. Для проверки поставтье еще один printf после слипа....
Можно также укзать флажок WT_EXECUTELONGFUNCTION в QueueUserWorkItem
Здравствуйте, TarasCo, Вы писали:
TC>Sleep(1000) — эта строчка не понравилась. Нехорошо наверное тормозить рабочий поток надолго. Система может "заподозрить" неладное и прибить его например. Для проверки поставтье еще один printf после слипа....
TC>Можно также укзать флажок WT_EXECUTELONGFUNCTION в QueueUserWorkItem
О, спасибо за подсказку. Оказалось все банально — программа просто-напросто завершалась, и соответственно все последующие вызовы ThreadProc прибивались. Если программа будет выполняться дальше, то и вызовы будут происходить как надо. По поводу потока — из-за Sleep() система не может его убить, да и этот Sleep только как тест использовался — в реале не его месте всякий долгострой крутится...
И еще по ходу появился вопрос — какие-то крайности получаются с количеством потоков в пуле — либо по числу процессоров (т.е. в большинстве случаев 1) либо, при использровании WT_EXECUTELONGFUNCTION — сколько будет запросов (а ну как придет 100 или 1000 — так сервер и ляжет

нельзя ли сделать чтобы было Threads = CPU*2?
(интересно, а HT в P4 считается?)