Мобильность pthreads-win32 по различным компиляторам окон
Я использую pthreads-win32, чтобы позволить распараллеливать поддержку окон.
У меня есть кросс-платформенный проект, который использует pthreads, и я хочу заставить его работать над окнами с различными компиляторами и различными версиями ОС.
По крайней мере, согласно документации pthreads-win32 должен работать с MSVC и даже обеспеченными сборками MSVC.
Но я не знаю, тестируется ли библиотека с последними компиляторами MSVC как MSVC 2008 и если она поддерживается окна на менее чем 64 бита.
На основе Вашего собственного опыта Вы знающий о каких-либо проблемах с этой библиотекой?
- Какие-либо проблемы с MSVC8, MSVC9, MSVC10?
- Какие-либо проблемы с Windows x86_64?
- Какие-либо проблемы с Windows Vista / Windows 7?
Примечания:
- Даже не пытайтесь рекомендовать использовать Повышение. Поток, я не интересуюсь. И я знаком с Повышением. Библиотека Thread
- Я не интересуюсь изобретением велосипед с Win32 API (который испытывает недостаток в RW-блокировках, Условных Переменных, и т.д.).
- Я сделал управляемый, чтобы скомпилировать проекты с MSVC 2008 и MinGW GCC-4.3 и затем выполнить модульные тесты на нем легко, с помощью текущего предварительно скомпилированного DLL pthreads.
Я просто должен знать ограничения pthreads-win32.
3 ответа
Ну, paxdiablo, видимо, подвел итог. Но из моего прошлого опыта работы с этой библиотекой я могу добавить пару вещей.
Во-первых, я использовал подмножество функций библиотеки в MSVC 2008 без каких-либо проблем.
Во-вторых, некоторые из моих коллег использовали ее на x86_64 (с MSVC2008 и MinGW). Они также не столкнулись ни с одной проблемой после многих циклов бета- и QA-тестирования. Хотя я сам не тестировал, поэтому не могу быть уверен в этом.
Так что, судя по всему, это может быть пригодно для использования. Единственная оговорка здесь заключается в том, что если вы обнаружите какую-либо проблему, вы будете во власти не очень активного списка рассылки (или, возможно, вы захотите запачкать руки исходным кодом или чем-то подобным).
Не могу сказать наверняка, и это может быть не то, что вы хотите услышать, но, учитывая, что последний релиз датирован 2006 годом, я бы очень опасался использовать это в последних компиляторах. Это может работать, но, скорее всего, вам придется решать, как это сделать. Кажется, есть много обсуждений о том, как заставить его работать в Cygwin и MinGW, но очень мало для MSVC, и ничего я не могу найти за пределами MSVC2005.
Кроме того, если вы изучите архивы CVS, там очень мало файлов, которые были обновлены за последний год (большинство - от двух до пяти лет назад). Пара файлов, которые датированы менее чем годом ранее, имеют описание "Комментарии и изменения стиля кода", что наводит меня на мысль, что ни одна из частей продукта не находилась в активной разработке в течение некоторого времени.
Возможно, я ошибаюсь, и это просто невероятно хорошо написанный, стабильный продукт, но моя внутренняя природа скорее склоняется к выводу, что это одна из миллиардов хороших идей, которые остались за бортом.
А если взглянуть на списки рассылки, то за первые пять месяцев 2010 года было опубликовано всего семь сообщений (самое раннее из которых оставалось без ответа четыре месяца), а за весь 2009 год - всего 59. Можете считать меня скептиком, но это не похоже на активное сообщество поддержки.
Кажется, есть патч для 64-битных Windows (см. здесь в архивах 2010 года), но, опять же, похоже, что у него есть проблемы, на которые нет ответов с февраля, и он упоминает только поддержку MinGW:
... этот патч (немного грубый и требующий окончательной очистки и некоторого расширения makefile тестового запуска для разрешения CROSS здесь) позволяет собирать pthread для цели x86_64-pc-mingw32.
Это не то, что я бы использовал для своего критически важного программного обеспечения.
И я знаю, что вы заявили, что не заинтересованы в повторном изобретении колеса, но вы можете реализовать многопользовательские блокировки и переменные состояния из более базовых примитивов довольно легко - у меня даже была схема многопользовательского чтения, которая решала проблему голодания при записи таким образом, что я почти получил патент (не то чтобы я был согласен с патентами на программное обеспечение, но мой работодатель настаивает на их ценности).
И если у единственного колеса, которое у вас есть, отсутствует половина спиц и оно ужасно выгнуто, вам, возможно, стоит пересмотреть свое мнение :-)
В любом случае, Vista и Server2k8 ввели как переменные состояния, так и тонкие блокировки читателя/писателя. Thread-local storage существует со времен Win2k. Я знаю, что это не поможет, если вам все еще нужно поддерживать XP, но я бы смотрел в будущее.
И поскольку вы, похоже, определили переносимость как "только для Windows", а все функции, которые вам нужны, доступны в текущих версиях, я не уверен, что вижу преимущество в использовании pthreads. Если бы вы хотели переносимости на POSIX, то да, но, похоже, это не тот случай.
Удивлен, что никто не предложил Intel Thread Building Blocks. Они очень активны и поддерживают практически все, причем последний выпуск был выпущен менее двух недель назад, а также функции C ++ 0x, если вы используете совместимый компилятор.