Цитата(Alca @ 1.9.2010, 13:45  ) |
| Join() |
и для этого приостанавливать основной поток? возможно логичнее было бы обеспечить нормальное завершение функции потока.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > Thread is finished |
| Автор: N1ko 1.9.2010, 12:28 | ||
Как мне понять когда поток закончит выполняться, дабы вызвать после его завершения какой нить MessageBox? |
| Автор: Alca 1.9.2010, 12:45 |
| http://msdn.microsoft.com/ru-ru/library/system.threading.thread_methods.aspx Join() |
| Автор: mrbrooks 1.9.2010, 13:13 | ||
и для этого приостанавливать основной поток? возможно логичнее было бы обеспечить нормальное завершение функции потока. |
| Автор: Alca 1.9.2010, 13:21 | ||||
| вот еще http://msdn.microsoft.com/ru-ru/library/system.threading.threadstate.aspx Добавлено через 1 минуту и 9 секунд
Добавлено через 2 минуты и 3 секунды
если Join() , то да |
| Автор: 6atoh 1.9.2010, 13:31 | ||
А что плохого в блокировании основного потока? Иногда это просто необходимо исходя из логики кода. |
| Автор: mrbrooks 1.9.2010, 13:45 | ||
встречно - а что хорошего? я за асинхронность. ее конечно тяжелее организовать, чем просто заблокировать основной поток.  по существу - я бы рекомендовал BackgroundWorker. |
| Автор: N1ko 1.9.2010, 14:05 | ||||
А можно ли сосздать код, который бы заменял работу BackgroundWorker? У меня уже просто их напихано штуки 3(каждый для разных операций)
Говоря про асинхронность Вы имете ввиду применение асинхоронных делегатов? |
| Автор: mrbrooks 1.9.2010, 15:01 | ||||||
конечно можно. правда не вижу в этом смысла.
по большому счету это не смертельно.
нет. я про асинхронное выполнение операций - как таковое. |
| Автор: 6atoh 1.9.2010, 15:28 | ||||
Я тоже за асинхронность  . Если вы имеете ввиду вызове Join() из основного потока формы, то здесь я с вами согласен, Join() однозначно будет злом. В таких случаях лучше использовать BackgroundWorker. А вообще, если говорить про работу с потоками в целом, Join вполне отлично справляется с некоторыми специфичными задачи, в которых требуется именно синхронность вызывающего потока.
Если вы имеете ввиду компонент, который бы инкапсулировал создание из запуск множества BackgroundWorker-ов, а также предоставлял возможности для модульного тестирования, могу привести вам исходники такого компонента, который я писал для собственных нужд. |
| Автор: azesmcar 1.9.2010, 15:35 | ||||
Использовать Task и его возможности аля ContinueWith. Добавлено через 1 минуту и 48 секунд
говоря словами дядюшки Рихтера: поток - слишком дорогое удовольствие, чтобы выделять его под конкретную задачу. |
| Автор: mrbrooks 1.9.2010, 15:39 | ||
это я так понимаю одна из новинок .NET Framework 4? |
| Автор: azesmcar 1.9.2010, 15:41 | ||
 |
| Автор: mrbrooks 1.9.2010, 15:43 |
 блин, на работе чувствую себя отрезанным от цивилизации. |
| Автор: azesmcar 1.9.2010, 15:55 | ||||
Класс Thread использовать не рекомендуется, используй ThreadPool, или как я уже писал Task-и, они работают через ThreadPool.
хорошего в блокировании потоков мало, этого надо по возможности избегать, поток нужен для паралеллизации, а если он просто спит и ничего не делает - то может он вообще не нужен? Усыплять поток можно тогда, когда программе вообще нечего делать, у многих 3 потока трудятся в поте лица, в то время как четвертый спит беспробудным сном, и почему бы тогда четвертому потоку не заняться делом вместо одного из тех трех? |
| Автор: Enter 1.9.2010, 16:47 | ||
эмм.. а из самого потока месседжбокс не вызывается? или если надо что-то в форме подправить, то делегат поможет |
| Автор: 6atoh 1.9.2010, 17:17 | ||
В ваших словах несомненно есть здравый смысл . Могу привести пример, когда усыпление потока необходимо. Представим ситуацию, что у нас есть 2 потока. Один поток - основной, второй - для выполнения фоновых операций. В определенный момент мы понимаем, что второй поток нам больше не нужен (пример - закрытие приложения). Если основной и дополнительный потоки используют совместно какие-либо ресурсы, мы обязаны дождаться завершения дополнительного потока, чтобы быть уверенными, что совместные ресурсы им больше не используются и их можно освобождать в основном потоке (там, где они были созданы).Впринципе, вы правильно сказали, что усыплять поток можно тогда, когда программе вообще нечего делать. В данном примере ей действительно нечего делать (ну, кроме как, научиться вышивать крестиком ). |