Здравствуйте, b0r3d0m, Вы писали:
AG>>Нет — критические секции в WinAPI не разделяются между процессами
B>Я про Mutex'ы.
AG>>Именно поэтому у меня и возник данный вопрос: AG>>можно ли в Qt, boost, STL использовать такие штуковины, как критические секции
B>Да что вы так WinAPI боитесь-то? Напишите свой враппер, протестируйте его и забудьте про детали реализации.
Во-первых — я не боюсь WinAPI.
Более того, работал на старой работе в течение примерно 5-ти лет очень плотно и с WinAPI, и с MFC.
Посему и понимаю как достоинства, так и недостатки данного стека технологий.
Достоинство — хорошая оптимизация по производительности под ОС семейства Windows.
Дальше начинаются недоститки: нет кроссплатформенности — главный и основной из них.
Отсутствие лаконичности — "монстроидальность" недостаток небольшой, всегда можно найти класс-обёртку (на худой конец — взять что-то из MFC).
Во-вторых я прекрасно понимаю, что на сегодняшний день надо осваивать кроссплатформенные технологии.
Если завтра мой код придется портировать на Linux, то это портирование должно проходить максимально беспроблемно.
И вот тут уже "альтернативние" средства работы с многопоточностью начинают сильно проигрывть по производительности: http://stackoverflow.com/questions/9997473/stdmutex-performance-compared-to-win32-critical-section
Относительно неплохим вариантом здесь выглядит свой собственный класс-обёртка,
оптимизированный к требованиям моего конкретного проекта и "скрывающий" детали реализации механизмов многопоточности.
Таким образом, мы будем иметь два таких класса — один для WinAPI, другой — для Linux.
Оба этих класса — должны наследовать общий интерфейс (aka абстрактный базовый класс).
B>Алсо, у Microsoft есть заголовочный файл concrt.h, в котором, помимо всего прочего, есть обёртка над критическими секциями. Насколько он публичный, я не в курсе, надо гуглить.
Есть такая штука, но это достаточно "редкий зверь".
И нет уверенности, что он не привязан к специфике конкретной ОС или студии. Его применение не выглядит как верное решение.
Вместо этого, для Windows можно всю обертку сделать на чистом WinAPI.
Здравствуйте, PM, Вы писали:
PM>Вообще в Windows Vista кроме Aero темы появилось новое ядро с новыми примитивами: CONDITION_VARIABLE и SRWLOCK. Последний можно использовать в реализации std::mutex, но не знаю так ли это в Visual C++
PM>https://msdn.microsoft.com/en-us/magazine/jj721588.aspx
Я бы, честно говоря, использовал везде std::mutex и все. Ну может быть boost::mutex если нужен бустовый thread::interrupt.
CK>Я бы, честно говоря, использовал везде std::mutex и все. Ну может быть boost::mutex если нужен бустовый thread::interrupt.
Кстати, я лично натыкался на один очень неприятный баг std::mutex -- его использование в DLL ведёт к увеличению счётчика ссылок на эту самую DLL без последующего уменьшения (следовательно, хост-процесс не выгрузит её при вызове FreeLibrary, так что не будет вызвана функция DllMain и деструкторы объектов со static storage duration).
Здравствуйте, AlexGin, Вы писали:
S>>Ну так приоткройте тайну, может вам более конкретные вещи посоветуют. AG>Обработка данных. Эта обработка должна быть распараллелена по всем ядрам CPU.
AG>Ну а дальше — создать столько потоков (threads), сколько у нас ядер — и считать. AG>Все потоки считают по одинаковому алгоритму, складывают данные (результаты) в общие коллекции. AG>Вот собственно и все премудрости.
OpenMP или Intel.TBB. Это простой кейс — data-parallel алгоритм. Если делать это не через OpenMP итп то нужно подумать вот о чем:
— Какой минимальный размер входных данных, при которых нужно начинать выполнять обработку параллельно?
— На блоки какого размера разбивать входные данные (их нельзя разбить на N блоков, где N-количество цпу).
— Как балансировать нагрузку.
— Как складывать результаты (если в одну общую коллекцию, то тут нужно избежать false-sharing-а и race-ов, а также правильно организовать синхр-ю, чтобы не получить падение производительности, вместо прироста, если каждый поток будет писать в свою коллекцию (более предпочтительно), то нужно подумать о том, как объединять результаты).
В общем, это все делается элементарно, если есть parallel for или его аналог, мне кажется такое сейчас и в Qt должно быть.
Здравствуйте, b0r3d0m, Вы писали:
B>Кстати, я лично натыкался на один очень неприятный баг std::mutex -- его использование в DLL ведёт к увеличению счётчика ссылок на эту самую DLL без последующего уменьшения (следовательно, хост-процесс не выгрузит её при вызове FreeLibrary, так что не будет вызвана функция DllMain и деструкторы объектов со static storage duration).
Потому что люди, пишущие на winapi, должны страдать.
Здравствуйте, AlexGin, Вы писали:
AG>Какие могут быть соображения по выбору? AG>Огромное спасибо, за любые мысли!
Соображение очень простое. Не та проблема ставится. Она надуманная. Используй самый простой инструмент, он по скорости будет ничем не хуже. А скорость будешь потом искать, профайлером.
CK>Очень очень старая хрень, думаю что это не основное средство для разработки windows приложений уже давно
Что именно? CRITICAL_SECTION? Оно ещё как в ходу.
Здравствуйте, b0r3d0m, Вы писали:
B>Что именно? CRITICAL_SECTION? Оно ещё как в ходу.
Если серьезно — MS делает свою стандартную библиотеку с человеческими примитивами синхронизации не просто так, наверное, а из расчета, что ей будут пользоваться.
CK>Если серьезно — MS делает свою стандартную библиотеку с человеческими примитивами синхронизации не просто так, наверное, а из расчета, что ей будут пользоваться.
std::mutex-то? Я ведь уже сказал, что в нём неплохой такой баг есть, а так я и не против его использования, где я говорил обратное?
Здравствуйте, b0r3d0m, Вы писали:
B>std::mutex-то? Я ведь уже сказал, что в нём неплохой такой баг есть, а так я и не против его использования, где я говорил обратное?
