Значительно ли отличаются проблемы многопоточности для «программистов системного уровня» на C / C ++ от тех, с которыми сталкиваются Java-программисты? - PullRequest
3 голосов
/ 13 марта 2009

Я ищу работу по разработке и вижу, что во многих списках указано, что разработчики должны разбираться в многопоточности. Это появляется как для списков вакансий Java, так и для списков C ++, которые включают «системное программирование» в UNIX.

В последние несколько лет я работал с Java и использовал различные механизмы синхронизации.

В конце 90-х я много работал на C ++, хотя и очень мало. Однако в колледже мы использовали темы на Solaris.

Мой вопрос заключается в том, существуют ли существенные различия в проблемах, с которыми сталкиваются разработчики на C / C ++, по сравнению с разработчиками на Java, и есть ли какие-либо из методов для их решения принципиально иными. Java, очевидно, включает в себя некоторые более приятные механизмы и синхронизированные версии коллекций и т. Д.

Если я хочу обновить или переучить потоки в UNIX, какой подход лучше? На какую библиотеку мне посмотреть? и т.д. Есть ли какое-нибудь отличное руководство по потокам в c ++?

Ответы [ 6 ]

7 голосов
/ 13 марта 2009

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

С C ++ у вас гораздо больше шансов на повреждение памяти и «невозможные» условия гонки. И вам нужно будет написать гораздо больше низкоуровневых потоковых примитивов или полагаться на библиотеки (например, boost), которые не являются частью стандартизированного языка.

4 голосов
/ 13 марта 2009

C ++ на самом деле проще для написания сложного многопоточного кода, чем Java, потому что у него есть особенность, которой нет в Java - RAII или "получение ресурсов - инициализация". Эта идиома используется для всего управления ресурсами в хорошо написанном коде C ++, но особенно подходит для многопоточного кода, где автоматическое управление синхронизацией является обязательным.

3 голосов
/ 13 марта 2009

Посмотрите на pthreads и boost (pthreads one был случайным lijnk, но в качестве отправной точки это выглядит нормально).

На высоком уровне проблемы для Java / C / C ++ / одинаковы. Особенности решения проблемы (вызываемые функции, создаваемые классы и т. Д.) Меняются от языка к языку.

3 голосов
/ 13 марта 2009

Сборка мусора делает программирующие потоки, которые не пропускают память, проще, и есть причудливые вещи , которые вы можете сделать для определения времени сбора.

Детерминированные деструкторы облегчают программирование потоков, которые не порождают зомби, см. Статью ACM здесь

1 голос
/ 13 марта 2009

Это зависит от того, на каком уровне вы решили работать. Intel TBB и OpenMP обрабатывают много общих случаев с довольно высокого уровня. Потоки Posix, API-интерфейсы Windows и переносимые библиотеки, такие как потоки Boost, приближают вас к тому же уровню, что и примитивы в Java.

C ++ 0x многопоточность (особенно с барьерами памяти получения и выпуска) позволяет вам перейти на еще более низкий уровень для большего контроля и сложности, чем предлагает Java (выделение переменной volatile в Java дает ей как приобретение, так и освободить барьер памяти, но в Java вы не можете запрашивать только получение или только барьер освобождения; где в C ++ 0x вы можете).

Обратите внимание, что модель многопоточности C ++ 0x преднамеренно низка, в надежде на то, что люди будут строить такие вещи, как TBB, и в следующий раз, когда комитет по стандартизации соберется, они смогут выяснить, кто из этих более высоких библиотеки уровней и инструментарий работают достаточно хорошо, чтобы учиться у них.

0 голосов
/ 13 марта 2009

Независимо от используемого языка программирования, характерная черта потока является обычной. Например, даже в ОС потоки POSIX и потоки WIN32 имеют одинаковый набор логических особенностей, хотя вызовы API и встроенная реализация WRT аппаратного обеспечения / ядра могут измениться, но системным программистам логическое представление о потоках и о том, как заставить их работать так, как ожидается И в достижении этого - самая трудная часть. Это даже верно при переходе на языки программирования. Если вы действительно понимаете концепцию потоков и синхронизации потоков, вы можете использовать их на любых языках программирования, которые вам нравятся. Поскольку эти языки программирования предоставляют синтаксические сахара поверх собственной реализации синхронизации потоков / потоков.

...