Здравствуйте

Есть ли возможность ускорить создание рабочего потока в программе для многопроцессорной машины?
Мне кажется, что функция AfxBeginThread() занимает слишком много процессорного времени, а если потоки в счетной программе создаются довольно часто а функция выполняется быстро, то собственно создание потока очень тормозит счет.
Сейчас потоки создаются так:

UINT fun_p(LPVOID WinPtr) { ((CCalcDoc*)((Inf*)(WinPtr))->pDoc)->fun(((Inf*)(WinPtr))->n); return 0; }
void CCalcDoc::fun(int par)
{
 ...

 End_Calc[par].SetEvent();
}

void CCalcDoc::Calculate()
{
 ...
// создание потоков
  for(i=0;i<N_PROC;i++) 
  {
      End_Calc[i].ResetEvent(); 
      AfxBeginThread(fun_p,(LPVOID)(aInf+i));
  }
  for(i=0;i<N_PROC;i++) ::WaitForSingleObject(End_Calc[i].m_hObject,INFINITE); 
}

Пробовал вариант

  for(i=0;i<N_PROC;i++) 
  {
      End_Calc[i].ResetEvent(); 
      pThread[i]=new CWinThread(fun_p,(LPVOID)(aInf+i));pThread[i]->m_bAutoDelete=TRUE;
      pThread[i]->CreateThread();
  }

Но время создания потока практически не уменьшилось.

С уважением
Андрей

Здравствуйте and_tjurin, Вы писали:

AT>Здравствуйте

AT>Есть ли возможность ускорить создание рабочего потока в программе для многопроцессорной машины?
AT>Мне кажется, что функция AfxBeginThread() занимает слишком много процессорного времени, а если потоки в счетной программе создаются довольно часто а функция выполняется быстро, то собственно создание потока очень тормозит счет.

Попробуй сишниые _beginThread и _endThread. MFC много бороды инициализирует в AfxBeginThread().

А ещё лучше апишные заюзай CreateThread и тому подобное.

Здравствуйте PSP, Вы писали:

PSP>Здравствуйте and_tjurin, Вы писали:

AT>>Здравствуйте

AT>>Есть ли возможность ускорить создание рабочего потока в программе для многопроцессорной машины?
AT>>Мне кажется, что функция AfxBeginThread() занимает слишком много процессорного времени, а если потоки в счетной программе создаются довольно часто а функция выполняется быстро, то собственно создание потока очень тормозит счет.

Ты уверен что время жрется в самом создании потока? Если да то:
используй _beginThread. Они правильно инициализируют сишную run-time библиотеку.
Насчет CreateThread — еэто наиболее быстрый способ но и чреват последствиями при неосторожном использовании сишных функций (на самом деле _beginThread после инициализации вызывает CreateThread).
Не стоит использовать что то связанное с MFC так как там слишком много инициализации убивающей время

Здравствуйте.

Попробовал API-шную CreateThread()
Действительно, поток создается побыстрее (раза в два).
Для меня это конечно маловато , но все-таки ...
И еще... По моим примерным прикидкам создание потока занимает столько же времени, сколько цикл до ~1000 с десятком операторов умножения в теле цикла. Очень печально ...

С уважением
Андрей

Здравствуйте and_tjurin, Вы писали:

AT>Попробовал API-шную CreateThread()
AT>Действительно, поток создается побыстрее (раза в два).
AT>Для меня это конечно маловато , но все-таки ...

Ну, быстрей уже не будет.

AT>И еще... По моим примерным прикидкам создание потока занимает столько же времени, сколько цикл до ~1000 с десятком операторов умножения в теле цикла. Очень печально ...

Хм, а ты чего хотел? Это не так-то просто — поток создать!

Здравствуйте and_tjurin, Вы писали:

AT>Попробовал API-шную CreateThread()
AT>Действительно, поток создается побыстрее (раза в два).
AT>Для меня это конечно маловато , но все-таки ...
AT>И еще... По моим примерным прикидкам создание потока занимает столько же времени, сколько цикл до ~1000 с десятком операторов умножения в теле цикла. Очень печально ...

Ну если настолько критично время создания... Извини, но имхо решение лежит на поверхности. Пул потоков создаем при инициализации приложения (когда время создания чего-то там безразлично), а потом просто правильно организовываем работу с ним. Да, геморрой. Да, расход памяти. Но за скорость нужно же чем-то заплатить.

Здравствуйте and_tjurin, Вы писали:

AT>Здравствуйте

AT>Есть ли возможность ускорить создание рабочего потока в программе для многопроцессорной машины?

Если мне не изменяет память при запуске каждого потока вызывается функция DllMain с флагом DLL_THREAD_ATTACH для каждой загруженной на данный момент dll-ки. Возможно какая-нибудь из них при этом съедает много времени, можно поэкспериментировать.
Но наиболее удобно наверно все-таки как уже и говорили, заранее создать пул потоков, если это возможно в твоем случае.

Здравствуйте Lostar, Вы писали:

L>Если мне не изменяет память при запуске каждого потока вызывается функция DllMain с флагом DLL_THREAD_ATTACH для каждой загруженной на данный момент dll-ки.

Угу, это так. В принципе это можно и отключить.

Здравствуйте.

L>>Если мне не изменяет память при запуске каждого потока вызывается функция DllMain с флагом DLL_THREAD_ATTACH для каждой загруженной на данный момент dll-ки.

A>Угу, это так. В принципе это можно и отключить.

Нашел по этому поводу функцию

BOOL DisableThreadLibraryCalls( HMODULE hLibModule 
 // dynamic-link library for which calls are to be disabled 
);

но так и не понял, какую dll-ку отключать. Мои функции не в dll, хотя сам проект создан как Shared DLL.

С уважением
Андрей

Здравствуйте and_tjurin, Вы писали:

AT>но так и не понял, какую dll-ку отключать. Мои функции не в dll, хотя сам проект создан как Shared DLL.

MSDN:
... To implement the optimization, modify a DLL's DLL_PROCESS_ATTACH code to call DisableThreadLibraryCalls.

Здравствуйте Lostar, Вы писали:

L>Здравствуйте and_tjurin, Вы писали:

AT>>но так и не понял, какую dll-ку отключать. Мои функции не в dll, хотя сам проект создан как Shared DLL.
Ты вообще какие-нибудь свои dll-ки явно/неявно грузишь?
С остальными dll-ками конечно не ясно, возможно их можно отключить при помощи вызова этой функции из exe-шника но как это скажется на их поведении сложно сказать...

Здравствуйте.

AT>>>но так и не понял, какую dll-ку отключать. Мои функции не в dll, хотя сам проект создан как Shared DLL.
L>Ты вообще какие-нибудь свои dll-ки явно/неявно грузишь?
L>С остальными dll-ками конечно не ясно, возможно их можно отключить при помощи вызова этой функции из exe-шника но как это скажется на их поведении сложно сказать...

Вообще-то да ... Подгружаю одну свою dll. В ней правда нет никаких функций, используемых при счете, но после того как поставил в DllMain DisableThreadLibraryCalls(...) заметил, что потоки создаются быстрее. Спасибо.

С уважением
Андрей Тюрин

Здравствуйте Lostar, Вы писали:

L>Здравствуйте Lostar, Вы писали:

L>>Здравствуйте and_tjurin, Вы писали:

AT>>>но так и не понял, какую dll-ку отключать. Мои функции не в dll, хотя сам проект создан как Shared DLL.
L>Ты вообще какие-нибудь свои dll-ки явно/неявно грузишь?
L>С остальными dll-ками конечно не ясно, возможно их можно отключить при помощи вызова этой функции из exe-шника но как это скажется на их поведении сложно сказать...

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

Здравствуйте Atilla, Вы писали:

A>Здравствуйте Lostar, Вы писали:

L>>Здравствуйте Lostar, Вы писали:

L>>>Здравствуйте and_tjurin, Вы писали:

AT>>>>но так и не понял, какую dll-ку отключать. Мои функции не в dll, хотя сам проект создан как Shared DLL.
L>>Ты вообще какие-нибудь свои dll-ки явно/неявно грузишь?
L>>С остальными dll-ками конечно не ясно, возможно их можно отключить при помощи вызова этой функции из exe-шника но как это скажется на их поведении сложно сказать...

A>Думаю, если потоки их использовать не будут, то ничего страшного не случится.

Имхо даже если и будут, то не случится. Нотификация о факте присоединения к потоку нужна лишь для случаев, когда по этому поводу необходимо выполнить определенные действия. Если таковые не предусматриваются, то можно смело это дело отключать. Кстати, майкрософтовский код DllMain(), подставляемый по-умолчанию (при отсутствии пользовательской реализации DllMain()), блокирует эту нотификацию вызовом DisableThreadLibraryCalls() при присоединении к процессу.