вопросы по потокам.... Опции

[Snake_B]

проведите кто-нибудь ликбез по потокам ))

такие вот вопросы... есть у меня в программе функции обработки картинок... если их вынести в отдельные потоки, будут ли задействованны вторые там ядра у новых процессоров?
(под делфи 2005)

[volvo]

а сколько потоков максимально стоит создавать?

Сколько нужно, столько и создавай. Потоки - они не просто так создаются. Скажем, пишешь ты VCL-приложение, и тебе нужно сделать какое-то длительное действие. Напишешь его в том же потоке - получишь "зависание" GUI, пока действие не закончится. Лечится, конечно, костылем ProcessMessages, но проще вынести вычисления в отдельный поток, чтоб они не мешали работе с интерфейсом.

Учти, чем больше потоков ты создашь, тем больше тебе нужно будет заботиться об их взаимодействии. Если же у тебя потоки абсолютно независимы друг от друга (не читают данные из одного файла, не пишут в один файл, и так далее) - то оптимальное число потоков = число ядер * количество процессоров. Будешь делать больше - ускорения вычислений точно не получишь. Больше можно делать только, чтоб не "завешивать" основной поток на время выполнения "длительной" задачи.

[Snake_B]

Сколько нужно, столько и создавай. Потоки - они не просто так создаются.

да меня и без них устраивает... но думается, что можно ими ускорить обработку (у меня то лично одноядерный))

Скажем, пишешь ты VCL-приложение, и тебе нужно сделать какое-то длительное действие. Напишешь его в том же потоке - получишь "зависание" GUI, пока действие не закончится. Лечится, конечно, костылем ProcessMessages, но проще вынести вычисления в отдельный поток, чтоб они не мешали работе с интерфейсом.

было такое... сделал в отдельной программе на винапи...
сейчас ещё есть отправка отчетов всяких на e-mail... программа во время отправки зависает... но если сделать в потоке, я же его остановить не смогу если что? или смогу?

Учти, чем больше потоков ты создашь, тем больше тебе нужно будет заботиться об их взаимодействии. Если же у тебя потоки абсолютно независимы друг от друга (не читают данные из одного файла, не пишут в один файл, и так далее) - то оптимальное число потоков = число ядер * количество процессоров.

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

то оптимальное число потоков = число ядер * количество процессоров.

вот тут и вопросы возникают... по хорошему получается надо определять индивидуально сколько этих самых
"число ядер * количество процессоров" есть и столько потоков создавать... так?

Будешь делать больше - ускорения вычислений точно не получишь. Больше можно делать только, чтоб не "завешивать" основной поток на время выполнения "длительной" задачи.

да в общем понятно, что быстрее не будет... просто, чтобы не определять количество ядер сделать 4 потока... будет 4 ядра - будет быстрее, не будет - не будет медленне (вот тут и вопрос - не будет ли медленне)....
хотя по хорошему так не правильно, наверно, это счас 4 ядра на топовых... а если через пару лет кто то программу будет использовать и ядер будет 8... лучше наверно определять их количество... да? ))

п.с. и ещё один вопрос не по теме...
вот в DRKB:

так как код использует GetTickCount, возвращающий в миллисекундах время с момента старта системы, это необходимо для ежечасной инициализац ии кода выполнения задачи. По-моему это то, что вам нужно. Величина, возвращаемая GetTickCount имеет тип DWORD, но Delphi ее хранит как LongInt, поэтому большие значения могут иметь отрицательную величину (после примерно 25 дней).

у меня программа считает сколько времени она отработала (люблю статистику)) и вот я заметил, что она иногда уходит в минус (я пока не уверен когда именно она это делает).... получается это из этого - "большие значения могут иметь отрицательную величину"? (в общем то других причин там быть не должно).... как с этим можно бороться?

"var TimeLaunchProg: integer;"
при запуске программы "TimeLaunchProg:=GetTickCount;"
при закрытии "Сounter:=GetTickCount - TimeLaunchProg;"
ну и там обработка...

Сообщение отредактировано: Snake_B - 20.09.2010 0:14