Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и правильно, что забыл. Нечего ее вызывать. Некрасиво это
Для того чтобы рассуждать красиво или не красиво, нужно знать что же делается в этих тредах. Пока мы не знаем какую задачу он выполняет, ничего сказать нельзя.
Здравствуйте, GlebZ, Вы писали:
GZ>Для того чтобы рассуждать красиво или не красиво, нужно знать что же делается в этих тредах. Пока мы не знаем какую задачу он выполняет, ничего сказать нельзя.
И все равно ее вызывать неприлично. Если не говорить о убиении потоков в чужом процессе, то ИМХО всегда можно сделать так, чтобы поток сам себя корректно завершал.
Здравствуйте, VladD2, Вы писали:
VD>Во, ПК, гляди (!) как искусно "юзаются" твои любимые деструкторы и RAII. Тут хоть кол на голове теши, но пока в библиотеке не напишут грамотную обертку народ будет мучаться, плакать, но жрать этот долбанный кактус.
Кстати да, есть на что посмотреть. Как на исключение, которое подтверждает правило. При использовании деструкторов и RAII этот код выглядел бы гораздо проще.
И для другого правила этот пример так же служит исключением -- готовые библиотеки нужно использовать.
Ты еще не знаешь, во что подобными исключениями из правил можно программы на C# превратить
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И все равно ее вызывать неприлично. Если не говорить о убиении потоков в чужом процессе, то ИМХО всегда можно сделать так, чтобы поток сам себя корректно завершал.
Фактически да. В подавляющем количестве случаев можно выйти корректно, или некорректно, но детерменированое, через exception. Трудно придумать ситуацию где такое понадобится TerminateThread. И вообще, тут ошибка. Сразу не подумавши был, из-за вечернего времени. В случае чего должен быть не TerminateThread а _endthreadex.
Здравствуйте, eao197, Вы писали:
E>Используй готовые библиотеки классов для работы с многопоточностью и синхронизацией.
Не канает использование готовых библиотек так как этот проект будет в дальнейшем будет портироватся на другую OS.
Здравствуйте, iix, Вы писали:
iix>Здравствуйте, eao197, Вы писали:
E>>Используй готовые библиотеки классов для работы с многопоточностью и синхронизацией. iix>Не канает использование готовых библиотек так как этот проект будет в дальнейшем будет портироватся на другую OS.
Здравствуйте, iix, Вы писали:
iix>Здравствуйте, eao197, Вы писали:
E>>Используй готовые библиотеки классов для работы с многопоточностью и синхронизацией. iix>Не канает использование готовых библиотек так как этот проект будет в дальнейшем будет портироватся на другую OS.
Как сказали выше есть кроссплатворменные библиотеки для этого.(например, в boost-е что было www.boost.org ), а во-вторых код итак не очень кроссплатформеный, т.к. встречаются
— CreateMutex
— TerminateThread
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, GlebZ, Вы писали:
GZ>Вообще очень занятный код. Если мы терминировали потоки, то кто же удалять мутексы будет? Вобщем, здесь логика по самое нехочу.
Во первых мютекс создает основной поток, он же его и удалит, ничего сложного в етом нету . А логика вот в чем ето функция выполняется в основном потоке. Она создает два потока и для них создает 2 мютекса. Мютексы нужны для того чтобы ети два потоко отправляли и принимали данные по очереди. Вот и все
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
GZ>Фактически да. В подавляющем количестве случаев можно выйти корректно, или некорректно, но детерменированое, через exception. Трудно придумать ситуацию где такое понадобится TerminateThread. И вообще, тут ошибка. Сразу не подумавши был, из-за вечернего времени. В случае чего должен быть не TerminateThread а _endthreadex.
Ох, не надо. Так ты закончишь не тот тред, что запустил, а самого себя
Тред должен заканчиваться endthreadex в самом себе. И закрыть перед этим хендл. Или просто return. Перед этим он должен как-то уведомить родителя, чтобы тот сделал CloseHandle у себя (счетчик-то исходно равен 2). Если, конечно, он его не сделал сразу после запуска треда. Тогда вообще ничего не надо.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, GlebZ, Вы писали:
GZ>Вообще очень занятный код. Если мы терминировали потоки, то кто же удалять мутексы будет? Вобщем, здесь логика по самое нехочу.
Да нормальная логика. Мутексы надо закрыть после закрытия треда, который перед своим окончанием должен их освободить.
В общем, сначала создаем мутексы, потом треды, потом они ждут и отпускают мутексы, потом треды кончаются и извещают родителя, а он закрывает мутексы.
Здравствуйте, iix, Вы писали:
iix>Не канает использование готовых библиотек так как этот проект будет в дальнейшем будет портироватся на другую OS.
Серьезное основание
Особенно с учетом, что библиотеки и классы обертки как раз очень сильно облегчают перенос кода на другие ОС.
А если это еще и IM клиент, которому нужно поддерживать коммуникации, то очень рекомендую посмотреть в сторону ACE
-- там и многопоточности, и синхронизации, и коммуникациям уделяется самое пристальное внимание (для этого и написано). Да еще можно применить ACE_Reactor и ACE_Acceptor/ACE_Connector, тогда про ручное управление потоками можно будет совсем забыть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, iix, Вы писали:
iix>Во первых мютекс создает основной поток, он же его и удалит,
Это как? Круто. iix>ничего сложного в етом нету . А логика вот в чем ето функция выполняется в основном потоке. Она создает два потока и для них создает 2 мютекса. Мютексы нужны для того чтобы ети два потоко отправляли и принимали данные по очереди. Вот и все
Эх молодежь. Использование terminate сродни пустить человеку пулю в лоб, вместо того чтобы просто попросить его выйти. И соответсвенно, придется расчленять труп и вывозить куда-то.
Точно так же, если ты в C++ убиваешь тред, то вся выделенная им память остается. Максимум, terminate может быть использован в системах 24x7 когда у тебя StackOverflow. Чтобы хоть что-то сохранить. Никто не знает в каком состоянии находится система, и существует большая вероятность, что произойдут утечки памяти выделенные потоками.
В данном случае желательно иметь некоторый event, с помощью которого основная функция оповещает потоки о том, что они не нужны. И вот только тогда, детерменированно освободив всю занятую память и задестроив все объекты, потоки должны корректно выйти.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, iix, Вы писали:
iix>>Здравствуйте, eao197, Вы писали:
E>>>Используй готовые библиотеки классов для работы с многопоточностью и синхронизацией. iix>>Не канает использование готовых библиотек так как этот проект будет в дальнейшем будет портироватся на другую OS. LM>Как сказали выше есть кроссплатворменные библиотеки для этого.(например, в boost-е что было www.boost.org ), а во-вторых код итак не очень кроссплатформеный, т.к. встречаются LM>- CreateMutex LM>- TerminateThread
Как бы тебе по русски сказать ну чемь меньше готовых классов буду использовать тем лутше. А кстати ты бы лучше предложил свой вариант без оберток а мы бы посмотрели и все бы поняли .
<scipped> iix>Как бы тебе по русски сказать ну чемь меньше готовых классов буду использовать тем лутше.
А в чем минусы готовых кросс-платформенных классов?
iix> А кстати ты бы лучше предложил свой вариант без оберток а мы бы посмотрели и все бы поняли .
Зачем?! "Захват ресурса — есть инициализация"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, iix, Вы писали:
iix>>Не канает использование готовых библиотек так как этот проект будет в дальнейшем будет портироватся на другую OS.
E> E>Серьезное основание E>Особенно с учетом, что библиотеки и классы обертки как раз очень сильно облегчают перенос кода на другие ОС. E>А если это еще и IM клиент, которому нужно поддерживать коммуникации, то очень рекомендую посмотреть в сторону ACE
-- там и многопоточности, и синхронизации, и коммуникациям уделяется самое пристальное внимание (для этого и написано). Да еще можно применить ACE_Reactor и ACE_Acceptor/ACE_Connector, тогда про ручное управление потоками можно будет совсем забыть.
Ну лан раскусили люблю я маненько помудится и написать свой код.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, iix, Вы писали:
LM><scipped> iix>>Как бы тебе по русски сказать ну чемь меньше готовых классов буду использовать тем лутше. LM>А в чем минусы готовых кросс-платформенных классов?
Я просто придерживаюсь идеологии все универсальное работае не очень быстро.