Как определить мультипоточное приложение или нет ?

Подскажите способы определения мультипотчного приложения win32.

 

Наличие CreateThread в импорте. Если ипользеутся дотнет или еще что-нибудь такое, то не знаю.

 

rmka
Ой как не факт ...

Skillax
Посчитать количество потоков, если больше одно то это многопоточное

 

П.С. Хотя может быть много поточным , вот только потом может жить не все время ...

Тогда Загрузить в дебаггер и посмотреть не создает ли потоков ... Вообщем уточните задачу

 

shchetinin
В общем случае конечно не поможет, но если мы говорим о легальном софте, то этого должно быть достаточно.

 

rmka
А если DLL будет загружена? это ведь вполне легально ... на пример консольная тулза , подгружает DLL ... Или вы хотите все ссылки пройти по либам?

 

shchetinin
А в dll треды создаются каким-то особенным образом? Точно так же в импорте посмотреть.

 

rmka
Да, но надо сначало будет посмотреть какие либы вызывает exe, а потом еще пройтись по этим либам ... Да еще и не факт что то найдется (( Перспективка не очень ...

 

Нафиг это надо? Щас 99% многопоточные. У меня почему то предчувствие что автор хочет юзать какой-то метод который криво работает на многопоточных)) Лучше сделай нормальную синхронизацию, чем выдумывать кучу бажного кода по проверке на создание потоков, который будет подтверждать что 99% таки многопоточные.

 

onSide
Я ничего не собирался писать, мне это нужно для оптимизации работы системы и приложений которые запущены на многоядерном сервере. Есть наверно проги для просмотра кол-ва открытых потоков запущенных процессов ?

 

Skillax
Что значит "для просмотра"? Если просто посчитать количество, то это и диспчер задач умеет.

 

CreateToolhelp32Snapshot + Thread32First\Next

PS: Хотя порядок перебора потоков ф-ей Thread32Next и не документирован в мсдн, но практика и здравый смысл показывают, что они группируются по th32OwnerProcessID (видимо дергаются из KPROCESS.ThreadListHead), что упрощает подсчет числа потоков каждого процесса

 

Я так понял в любом приложений есть потоки, но меня интересует задействует или нет приложение несколько процессорных ядер.

 

Это в корне меняет суть вопроса. Тогда нужно прочекать кол-во потоков и проверить process affinity mask http://msdn.microsoft.com/en-us/library/ms683213(v=VS.85).aspx

 

Skillax
Сейчас во всех приложениях больше одного потока .. Что вы хотите добится этим? или это просто инфа?

 

Honorary_BoT
А может быть приложение быть многоядерным без api выставляющей маску ядер? т.к. винда для любого win32 или win64 приложения выставляет все биты маски в 1.

 

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

 

Skillax
вы думаете что сможете сделать планировщик лучше чем виндовский?

 

Honorary_BoT
Когда купили сервер заметного увеличения произваодительности работы 1c 7.7 не заметили, в 1С сказали что 7.7 не многопоточное и т.е. не расчитано на работу с несколькими процессорами, и нам нужно проапргейдить 7.7 на 8.0.
Как опрделить приложения которые нужно запускать с указанием ядра и для каких это не нужно ?
т.к. я читал что не многопроцовые приложения замедляют работу многопроцессорного компьютера.

 

Ну смотрите. Есть физические ресурсы железа. ОС управляет ими, превращая эти физические ресурсы в логические (виртуальные, не знаю, как грамотнее).
Пусть у вас два двухъядерника с гипертрэдингом. Т.е. гипертрединг по сути не дает отдельного физического ядра, но тем не менее он считается за ядро логическое - можно увидеть в таскманагере. То же самое и про остальные части, т.е. два физических проца - 2 логических, 2 физ ядра - х2 логических, гипертрединга - х2 логических, итого 2х2х2 = 8 логических ядер, на которых происходит выполнение кода.
Минимальная единица планирования в ОС Windows - поток. Распределением ядер как ресурса для выполнения потоков кода занимается ОС, автоматически. Можно вручную привязать потоки к ядрам, но программисты вряд ли этим будут заниматься, ещё и при учете того, что это отрицательно скажется на производительности.
Другое дело, что в программе могут быть места, которые либо поддаются распараллеливанию (-> увеличение быстродействия), либо грамотно были реорганизованы места, где потоки "отдыхали" вследствие синхронизации.
Вам просто ответили попроще, не вдаваясь в детали реализации приложения...