Нарезание резьбы на C, поперечная платформа

Ответ 1

Попробуйте OpenMP API, это многоплатформенный и вы можете скомпилировать его с помощью GCC.

Краткое описание из wikipedia:

OpenMP (Open Multi-Processing) - это интерфейс прикладного программирования (API), который поддерживает многоплатформенную многопроцессорную память программирование на C, С++ и Fortran, [3] на большинстве платформ, процессор архитектуры и операционные системы, включая Solaris, AIX, HP-UX, Linux, MacOS и Windows. Он состоит из набора компиляторов директивы, библиотечные процедуры и переменные окружения, которые влияют поведение во время выполнения.

Ответ 2

Я бы использовал API-интерфейс потока POSIX - pthread. В этой статье приведены некоторые рекомендации по ее внедрению в Windows и загрузка только для файлов заголовков (лицензия BSD):

http://locklessinc.com/articles/pthreads_on_windows/

Изменить: я использовал проект sourceforge pthreads-win32 в прошлом для многоплатформенной потоковой обработки, и он работал очень хорошо. С тех пор ситуация изменилась, и вышеупомянутая ссылка кажется более актуальной, хотя я ее не пробовал. Этот ответ предполагает, конечно, что pthreads доступны для ваших целей, отличных от Windows (для Mac/Linux я думаю, что они, возможно, даже встроены)

Ответ 3

Потоки Windows имеют достаточно разные функциональные возможности по сравнению с Linux, так что, возможно, вам стоит рассмотреть две разные реализации, по крайней мере, если производительность приложения может быть проблемой. С другой стороны, простое внедрение многопоточности может сделать ваше приложение медленнее, чем было раньше. Предположим, что производительность является проблемой и что многопоточность является наилучшим вариантом.

С потоками Windows я специально задумываюсь о портах завершения ввода/вывода (IOCP), которые позволяют внедрять потоки, связанные с вводом-выводом, которые наиболее эффективно используют аппаратное обеспечение.

Многие "классические" приложения создаются по одной концепции потока/одного сокета (или одного пользователя или аналогичного), где количество одновременных сеансов будет ограничено возможностью планировщика обрабатывать большое количество потоков ( > 1000). Концепция IOCP позволяет ограничить количество потоков количеством ядер в вашей системе, что означает, что планировщику будет очень мало. Потоки будут выполняться только тогда, когда IOCP освободит их после возникновения события ввода-вывода. Служба потоков IOC (обычно) инициирует новый ввод-вывод и возвращает ожидания в IOCP для следующего завершения. Перед выпуском нити IOCP также предоставит контекст завершения, чтобы поток "знал", к какому интерфейсу обработки принадлежит IOC.

Концепция IOCP полностью устраняет опрос, который является отличным ресурсом, хотя опрос "ждать на нескольких объектах" является чем-то вроде улучшения. В последний раз, когда я смотрел Linux, ничего не было отдаленно, как IOCP, поэтому многопоточное приложение Linux было бы построено совершенно по-другому по сравнению с приложением Windows с IOCP.

В действительно эффективных приложениях IOCP существует риск того, что так много IO (или, скорее, Outputs) поставлены в очередь на IO-ресурс, связанный с тем, что в системе не хватает памяти без памяти для их хранения. И наоборот, в действительно неэффективных приложениях IOCP существует риск того, что так много входов поставлены в очередь (ожидание обслуживания), что неиспользуемая память исчерпана при попытке временно их буферизовать.

Ответ 4

glib threads могут быть скомпилированы кросс-платформы.

Ответ 5

Учитывая, что вы ограничены C. У меня есть два предложения:

1) Я видел проект (похожий на ваш), который должен был запускаться в Windows и Linux с потоками. То, как это было написано, было то, что он (тот же код) использовал pthreads для Linux и win32-потоков в Windows. Это было достигнуто с помощью условного оператора #ifdef везде, где необходимо было создать потоки, такие как

#ifdef WIN32

//use win32 threads

#else

//use pthreads

#endif

2) Второе предложение может заключаться в использовании OpenMP. Вы рассматривали OpenMP вообще?

Пожалуйста, дайте мне знать, если я что-то пропустил, или вы хотите получить более подробную информацию. Я рад помочь.

Бест, Кришна

Ответ 6

"Лучший" / "самый простой" /... ответ здесь определенно pthreads. Это естественная потоковая архитектура на Unix/POSIX-системах и работает почти так же хорошо в Windows. Нет необходимости смотреть дальше.

Ответ 7

По моему опыту, многопоточность в C для Windows сильно привязана к API Win32. Другие языки, такие как С# и JAVA, поддерживаемые платформой, также привязываются к этим основным библиотекам, предлагая их классы потоков.

Однако, я нашел API-интерфейс openthreads на sourceforge, который может вам помочь:

http://openthreads.sourceforge.net/

API моделируется по стандарту потока Java и POSIX,

Я не пробовал это сам, так как в настоящее время мне не нужно поддерживать несколько платформ в моих проектах на C/С++.

Ответ 8

Если кому-то понадобится переносное и легкое решение для потоковой передачи на C, посмотрите библиотеку plibsys. Он обеспечивает управление потоками и синхронизацию, а также другие полезные функции, такие как перенос сокетов. Поддерживаются все основные операционные системы (Windows, Linux, OS X), поддерживаются различные другие менее популярные операционные системы (например, AIX, HP-UX, Solaris, QNX, IRIX и т.д.). На каждой платформе для минимизации накладных расходов используются только собственные вызовы. Библиотека полностью покрыта модульными тестами, которые запускаются на регулярной основе.