Переносимость pthreads-win32 по различным компиляторам Windows

Я использую pthreads-win32, чтобы разрешить поддержку потоков для окон.

У меня есть проект кросс-платформы, который использует pthreads, и я хочу, чтобы он работал с окнами с различными компиляторами и разными версиями ОС.

По крайней мере, согласно документации, pthreads-win32 должен работать с MSVC и даже Созданы сборки MSVC.

Но я не знаю, протестирована ли библиотека с последними компиляторами MSVC, такими как MSVC-2008 и если он поддерживается под 64-битными окнами.

От собственного опыта вы знаете о каких-либо проблемах с этой библиотекой?

  • Любые проблемы с MSVC8, MSVC9, MSVC10?
  • Любые проблемы с Windows x86_64?
  • Любые проблемы с Windows Vista/Windows 7?

Примечания:

  • Даже не пытайтесь рекомендовать использовать Boost.Thread, меня это не интересует. И я знаком с библиотекой Boost.Thread.
  • Мне не интересно изобретать колесо с API Win32 (у которого нет RW-Locks, условных переменных и т.д.).
  • Мне удалось скомпилировать проекты с MSVC-2008 и MinGW GCC-4.3, а затем легко запустить модульные тесты, используя текущую предварительно скомпилированную DLL pthreads.

Мне просто нужно знать ограничения pthreads-win32.

Ответ 1

Хорошо, paxdiablo, судя по всему, подвел итог. Но из моего прошлого опыта работы с этой библиотекой я могу добавить пару вещей здесь.

Во-первых, я использовал подмножество функций библиотеки с MSVC 2008 без каких-либо проблем.

Во-вторых, некоторые из моих коллег получили его на x86_64 (с MSVC2008 и MinGW). Они не сталкивались с какой-либо проблемой ни после многих циклов тестирования бета-тестирования и тестирования QA. Хотя я сам не тестировал его, поэтому не могу быть уверенным в этом.

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

Ответ 2

Не могу сказать наверняка, и это может быть не то, что вы хотите услышать, но, учитывая, что последний релиз датирован 2006, Я бы очень опасался использовать это в последних компиляторах. Это может сработать, но, вероятно, вам будет нужно, чтобы это произошло. Кажется, что есть много дискуссий о том, как работать в Cygwin и MinGW, но очень мало для MSVC, и я ничего не могу найти за пределами MSVC2005.

Кроме того, если вы просматриваете архивы CVS, в прошлом году было исправлено несколько файлов, которые были обновлены (большинство из них два-пять лет назад). Пары, датированные менее года назад, имеют описание "Комментарии и изменения стиля кода", что заставляет меня думать, что ни одно из мяса продукта не находилось в активном развитии на некоторое время.

Теперь, может быть, я ошибаюсь, и это просто невероятно хорошо написанный, стабильный продукт, но моя внутренняя природа с большей вероятностью сделает его одним из базой хороших идей, которые ушли на второй план.

И, взглянув на списки рассылки, в течение первых пяти месяцев 2010 года было опубликовано всего семь сообщений (самые ранние из которых остались без ответа в течение четырех месяцев) и всего 59 за весь 2009 год. Побалуйте меня скептически но это не похоже на массовое сообщество поддержки.

Кажется, что исправление для 64-битной Windows (см. здесь в архивах 2010 года), но, опять же, это похоже проблемы, которые остаются без ответа с февраля, и в нем упоминается только поддержка MinGW:

... этот патч (немного грубый и нуждается в некоторой окончательной очистке и некотором расширении к make файлу тестового запуска для разрешения CROSS здесь) позволяет создавать pthread для цели x86_64-pc-mingw32.

Это не то, что я буду использовать для своего критически важного программного обеспечения.

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

И если у единственного колеса, у которого есть половина его спиц, отсутствует и ужасно изогнута, вы можете просто пересмотреть: -)

В любом случае Vista и Server2k8 представили как переменные условия , так и тонкие блокировки чтения/записи. Тема-локальное хранилище существует со времен Win2k. Я знаю, что это не поможет, если вам все еще нужно поддерживать XP, но я буду смотреть в будущее.

И поскольку вы, похоже, определили переносимость как "только для Windows", и все функции, которые вы хотите, доступны в текущих версиях, я не уверен, что вижу преимущество придерживаться pthreads. Если вы хотите переносить POSIX, да, но это, похоже, не так.

Ответ 3

Удивлен, что никто не предложил Intel Thread Building Blocks. Они очень активны и поддерживают практически все, причем последний релиз составляет менее двух недель назад, а функции С++ 0x, если вы используете совместимый компилятор.

http://software.intel.com/en-us/intel-tbb/#sysreq