Здравствуйте, уважаемое Linux-сообщество!!!Начал изучать программирование под Linux.
До настоящего времени программировал под Windows.
Сейчас изучаю материал по разработке многопоточных приложений. Но как-то все туманно по этой теме. Как я понял, есть стандарт на API поддержки потоков – POSIX 1996. Затем наткнулся на инфу о библиотеках реализации неких пользовательских потоков. Затем слышал, что реализация поддержки многопоточности под Linux несколько кривовато, подглючивают проги, реализованные с использованием многопоточности.Подскажите, на что ориентироваться в этом вопросе??? Помогите пожалуйста дополнительной инфой и рекомендациями! Хотелось бы иметь возможность работы с потоками как это реализовано в Windows, т.е. потоки работают в рамках одного процесса (используют одно адресное пространство), потоки диспетчируются ядром, какие-либо системные вызовы в одном потоке никак не влияют на другие потоки, потоки располагают достаточными средствами синхронизации (хотя бы какие-нибудь критические секции) и т.д.
Также для меня важно использовать наиболее надежный вариант, чтобы проги ни дай бог не повели себя неадекватно.
Работать собираюсь под дистрами RedHat и CentOS.
Смотрите в сторону pthread pthread_create() pthread_join() и т.д
много по этой теме можно найти в man pthread
Более детально в книге UNIX: взаимодействие процессов
Уильям Стивенс
>Здравствуйте, уважаемое Linux-сообщество!!!
>
>Начал изучать программирование под Linux.
>До настоящего времени программировал под Windows.
>Сейчас изучаю материал по разработке многопоточных приложений.
>Но как-то все туманно по этой теме. Как я понял, есть стандарт
>на API поддержки потоков – POSIX 1996.SUSv3 поможет: http://www.unix.org/version3/online.html
Там надо сперва зарегистрироваться, потом можно скачать. В числе прочих
материалов приведено полное описание API для разработки многопоточных
программ. Соответственно, интересовать Вас будут функции, название
которых начинается с 'pthread_'.>Затем наткнулся на инфу о библиотеках реализации неких пользовательских
>потоков. Затем слышал, что реализация поддержки многопоточности под
>Linux несколько кривовато, подглючивают проги, реализованные с
>использованием многопоточности.Во всех известных мне UNIX-системах pthreads представляет собой обвертку над
собственной (системно-специфичной) реализацией многопоточности. Качество
реализации как собственных механизмов, так и "стандартизирующей" обвертки
бывает разным. До относительно недавнего времени в Linux рекомая обвертка
(под названием LinuxThreads) была, скажем так, своеобразной. Однако сейчас
ситуация изменилась, и любой более-менее свежий дистрибутив идет с весьма
достойной и качественной поддержкой pthread'ов.>Подскажите, на что ориентироваться в этом вопросе???
Ориентироваться лучше всего на стандарт. Тогда написанные в итоге программы
смогут работать без существенных изменений практически в любой UNIX-системе
(Solaris, HP-UX, AIX, ...).>Хотелось бы иметь возможность работы с потоками как это реализовано
>в Windows, т.е. потоки работают в рамках одного процесса (используют одно
>адресное пространство),Это обязательное свойство любой реализации pthreads.
>потоки диспетчируются ядром,
А это уже детали, которые едва ли окажут значимое влияние на работу Ваших
приложений. Схемы диспетчеризации бывают очень различными. В Solaris, например,
до недавнего времени по умолчанию использовалась схема NxM, когда N
пользовательских потоков исполнялось M потоками ядра.>какие-либо системные вызовы в одном потоке никак не влияют на другие потоки,
Недостижимое свойство, в том числе и в Windows. Например, дескрипторы файлов
глобальны для процесса, и закрыв файл в одном потоке, Вы не сможете продолжать
работать с ним в другом.Некоторую аккуратность необходимо соблюдать в обработке сигналов. Я обычно завожу
для их обработки отдельный поток, и ловлю их в нем sigwait()ом - а обработку
по умолчанию запрещаю pthread_sigmask()ом. Впрочем, дело вкуса.>потоки располагают достаточными средствами синхронизации
>(хотя бы какие-нибудь критические секции) и т.д.Мьютексы (pthread_mutex_init) и условия (pthread_cond_init) позволяют организовать
практически любую дисциплину синхронизации при доступе к общим ресурсам.>Также для меня важно использовать наиболее надежный вариант, чтобы проги ни дай
>бог не повели себя неадекватно.Не работать с системами, основанными на LinuxThreads. Использовать свежее ядро
и свежую glibc.>Работать собираюсь под дистрами RedHat и CentOS.
Главное, чтобы не старых версий.
Отлично! Спасибо за такой развернутый ответ!!!
Вы меня реально успокоили :), тепеть я со спокойной душой могу приступить к детальному изучению потоков :)
>>какие-либо системные вызовы в одном потоке никак не влияют на другие потоки,
>
>Недостижимое свойство, в том числе и в Windows. Например, дескрипторы файлов
>глобальны для процесса, и закрыв файл в одном потоке, Вы не сможете
>продолжать
>работать с ним в другом.не знаю как в вендовс обстоят дела с файловыми дескрипторами, а в линукс есть clone, и флаг к нему CLONE_FILES ;)
>не знаю как в вендовс обстоят дела с файловыми дескрипторами, а в
>линукс есть clone, и флаг к нему CLONE_FILES ;)Клоуны - это нездоровый низкоуровневый гибрид процесса с потоком.
В принципе удобно, но
(а) Linux-специфично
(б) IMHO провоцирует ошибки из-за возросшей сложности при выборе уровня изоляции