Вообщем у меня есть программа которая выгружает из БД файлы. Работа проходит быстро, но хотелось бы еще быстрее. Принцип работы таков: программа запускает поток в котором цикл, в каждой итерации цикла происходит  выгрузка файла. Довольно такой последовательный механизм. Хотелось бы сделать чтоб в каждой итерации цикла создавать свой поток на выгрузку одного файла. Есть два вопроса, первый чисто теоретический. Если в цикле 50 000 итераций и он создаст 50 000 потоков, то программа будет работать быстрее, не загнется? 
Как мне получить оповещение что поток прекратил работу?

Я правильно понял проблему? Есть программа, работающая хорошо и быстро, так вот вопрос в том, а не вхренячить ли в неё полста тысяч потоков и посмотреть не загнётся ли. А потом ещё если не загнётся, то чтобы каждый поток(из 50000) выдавал оповещение, что дескать, работа выполнена. 
А оповестить легко, месседжбоксы запустить из каждого, и потом вручную закрывать.

А если серьёзно, то мне как-то странно, что при таких условиях, вопрос в том, будет ли прога быстрее работать, а не медленнее. Я, конечно не пробовал(как-то не додумался), но мне почему-то кажется, что идея плохая. Многопоточность ведь это только видимость параллельного выполнения нескольких действий одновременно. Просто при такой расстановке сил будет создано 50000 лишних объектов и система вместо того, чтобы выполнять все действия в нужной последовательности будет метаться между потоками. Я тут не понимаю за счёт чего можно ожидать выигрыш в производительности, даже чисто теоретически. 

Хотя: я ни на чём не настаиваю - может и не прав.

тебе система столько не даст


событием например (не тем, которое - делегат, а тем, которое объект ядра)

Оптимальный вариант - асинхронный ввод-вывод

Добавлено через 1 минуту и 55 секунд
количество потоков должно зависеть от того, сколько процессоров - ядер на машине

севетую потестить. пускай сначала 2 потока, если есть реальный выигрыш - остановись на 2ух, 3 - уже толпа в мире 2уядерных машин)

На каждом разное, на моем одно, на других 2.

А сколько даст?

Что произойдет в данном случаи когда итерации перевалят за N?

все что угодно. от простых тормозов и и зависания,
до дедлоков и необходимости ребутить все нафик.
смотри у тебя 2 узких места минимум: количество ядер, хард.
Субд чтобы слить тебе инфу на хард -читает с него, хард занят, потом пишет в него - хард занят.
если все файлы у тебя уже в памяти а не на диске то выгружать одновременно все равно будет только 1 файл.
При увеличении количесва потоков все может начать работать медленнее.
потесть, говорю же

да где-то после сотни начнутся жуткие тормоза


все будет ограничено скоростью работы жесткого диска, системного кэша и самой БД, если можешь, сделай выгрузку асинхронной

Ок. Для этого нужно:

Можно немножко подробнее?

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

Добавлено через 45 секунд

я это на шарпе никогда не делал, на принцип не зависит от ЯП, хоть на питоне пиши)

MSDN перервыл не где не нашел онного, кинте ссылкой плизз!

http://msdn.microsoft.com/en-us/library/kztecsys(VS.71).aspx