CK>C++/CLI FTW!
Сами-то пробовали?

Здравствуйте, b0r3d0m, Вы писали:

CK>>Потому что люди, пишущие на winapi, должны страдать.
B>А на Linux посоветуете, что должны люди делать?

В Linux тоже "использование в DLL .so ведёт к увеличению счётчика ссылок на эту самую DLL .so без последующего уменьшения"?

Здравствуйте, b0r3d0m, Вы писали:

B>Всё ясно.

На плюсах я тоже пишу, с 2002-го года, если что. И даже Win32-api лет наверное пять использовал. Могу сравнивать.

Здравствуйте, b0r3d0m, Вы писали:

CK>>А ты его засабмитил куда следует?
B>Он уже до меня был засабмичен.

Забавно.

The trige meeting decided to not fix this particular issue. As a workaround it's recomended to terminate all the threads that were started or wait until they are finished.

Здравствуйте, b0r3d0m, Вы писали:

CK>>C++/CLI FTW!
B>Сами-то пробовали?

Неописуемо удобная штука, когда нужно много нативного кода в .NET проект интегрировать.

Здравствуйте, Dair, Вы писали:

D>В Linux тоже "использование в DLL .so ведёт к увеличению счётчика ссылок на эту самую DLL .so без последующего уменьшения"?

Похоже что там не сбрасывается счетчик только если есть живые потоки, запущенные из этой dll, сложно это багом назвать, честно говоря.

Они фигню сказали, в комментах уже успели обсудить этот "workaround".

D>В Linux тоже "использование в DLL .so ведёт к увеличению счётчика ссылок на эту самую DLL .so без последующего уменьшения"?
Нет. Да и в случае Windows это всего лишь баг в реализации стандартной библиотеки. Если использовать соответствующие примитивы синхронизации (например, ту же CRITICAL_SECTION) напрямую, то увеличения счётчика ссылок не наблюдается.

CK>Похоже что там не сбрасывается счетчик только если есть живые потоки, запущенные из этой dll
Нет, не только.

Здравствуйте, уважаемый velkin!
Огромное спасибо за столь развёрнутый ответ!

Скорее всего и остановим выбор именно на Qt!
По крайней мере в кроссплатформенной реализации.
Возможно, стоит применять Qt многопоточность даже для Windows реализации.
Тут надо проеэкспнриментировать — посчитать производительность, как она будет в сравнении с WinAPI.

V>Но принципиальной разницы в программировании для того и другого процессора нет, просто нужно определиться с общей стратегией.
Собственно этим и занимаюсь

Здравствуйте, chaotic-kotik, Вы писали:

PM>>Вообще в Windows Vista кроме Aero темы появилось новое ядро с новыми примитивами: CONDITION_VARIABLE и SRWLOCK. Последний можно использовать в реализации std::mutex, но не знаю так ли это в Visual C++

PM>>https://msdn.microsoft.com/en-us/magazine/jj721588.aspx

CK>Я бы, честно говоря, использовал везде std::mutex и все. Ну может быть boost::mutex если нужен бустовый thread::interrupt.

Я бы тоже Просто топикстартеру зачем-то понадобился высокопроизводительный mutex и я вспомнил, что SRWLOCK работает в userspace.

Кстати, посмотрел в Visual C++ 2015 update3, там до сих пор какая-то лабуда в виде `_Mtx_internal_imp_t` внутри std::mutex. Похоже из-за того, что приходится поддерживать Windows XP.

Здравствуйте, AlexGin, Вы писали:

AG>Возможно, стоит применять Qt многопоточность даже для Windows реализации.
AG>Тут надо проеэкспнриментировать — посчитать производительность, как она будет в сравнении с WinAPI.

Думаю пункт 1, то есть WinAPI существенной роли не сыграет, в особенности, если понимать на что влияют технологии многопоточного программирования Qt.

http://doc.qt.io/qt-5/threads-technologies.html
1) QThread: Low-Level API with Optional Event Loops
2) QThreadPool and QRunnable: Reusing Threads
3) Qt Concurrent: Using a High-level API

Третий пункт тоже не имеет значения:

AG>Дополнительная красота третьего пункта — если будет серверное приложение, без GUI, то не нужно "притягивать за уши" дополнительные библиотеки.

Я просто беру и создаю в QtCreator консольное приложение:

#-------------------------------------------------
#
# Project created by QtCreator 2016-07-06T21:15:33
#
#-------------------------------------------------

QT       += core

QT       -= gui

TARGET = untitled
CONFIG   += console
CONFIG   -= app_bundle

TEMPLATE = app


SOURCES += main.cpp

Немного причёсываем:

TARGET = untitled
TEMPLATE = app

QT -= gui

CONFIG += console
CONFIG -= app_bundle

SOURCES += main.cpp

А потом можно создать составной проект с общими файлами и включёнными проектами gui-клиента и сервера. Или вот маленькая переделка кода:

#include <QDebug>

int main(int argc, char *argv[])
{
    qDebug() << "Hello World!";
    return 0;
}

В дебиане нажимаем Ctrl+Alt+F1, вводим root или другого пользователя с паролем и запускаем программу. Потом обратно выход на рабочий стол Ctrl+Alt+F7. Фишка в том, что функционал отвечающий за работу с параллельными потоками исполнения лежит в модуле QtCore. Между прочим, если совместить кроссплатформенные библиотеки, то тоже выйдет неплохое кроссплатформенное решение. Другое дело это не всегда целесообразно, особенно, если можно обойтись средствами Qt.

Ещё когда-то давным давно обсуждали статическую сборку Qt для Windows

Автор:
Дата: 18.12.11

. По прошествии многих лет могу сказать, что идея тоже не целесообразна, хотя всё прекрасно работает. Суть в том, что чем больше программист создаёт себе проблем, тем хуже для него. Отсюда вывод, не создавать надуманных проблем, лучше не идеально работающая система, чем идеальная не работающая.

Я не зря привёл пример компьютеров с низкой и высокой вычислительной мощью. Сдаётся мне в прикладном приложении можно убить месяцы на разработку велосипеда, а школьник Вася Пупкин стандартным функционалом на коленеке сделает так же или даже лучше, плюс ещё и кроссплатформенно. При этом он может и слов таких не знать, которыми обменивались в этой теме.

Здравствуйте, AlexGin, Вы писали:


AG>Какие могут быть соображения по выбору?

Никаких, многопоточность уже входит в стандарт, ею и нужно пользоваться.
std::thread то есть.
При этом на производительность это либо вообще не повлияет, либо если и повлияет, то очень незначительно.

Здравствуйте, AlexGin, Вы писали:

AG>...
AG>Какие могут быть соображения по выбору?
AG>Огромное спасибо, за любые мысли!

Тут уже всё расписали. Оставлю пару ссылок:
Преждевременная оптимизация
Производительность примитивов синхронизации в Qt

Здравствуйте, chaotic-kotik, Вы писали:

CK>Win API функции тоже могут делать что-нибудь в user-space. Я не знаю как это точно реализовано в win-api (не писал ничего под эту платформу лет эдак шесть), но например в linux никто никогда не делает системные вызовы напрямую — все вызовы завернуты в вызовы glibc и тот же pthread_mutex_lock много чего делает в userspace прежде чем делать системный вызов, там в принципе может и без системного вызова обойтись. Подозреваю в win32 api что-то похожее, ну либо у них там мьютекс это действительно голый объект ядра, а поддержку в userspace имеют только критические секции.

В венде есть функция CreateMutex, она возвращает HANDLE (аналог, в некотором смысле, юниксного file descriptor) и именно этот объект виндовые программисты привыкли называть мьютексом. Любое телодвижение с ним — это системный вызов.

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

Такая вот культурно-терминологическая особенность.

Здравствуйте, AlexGin, Вы писали:

AG>Обработка данных. Эта обработка должна быть распараллелена по всем ядрам CPU.

Qt concurrent

AG>Как подсчитать количество ядер — дело ясное:
AG>

AG>    SYSTEM_INFO stInfo;
AG>    GetSystemInfo(&stInfo);
AG>    DWORD dwCPUCores = stInfo.dwNumberOfProcessors;
AG>

QThread::idealThreadCount()

AG>Ну а дальше — создать столько потоков (threads), сколько у нас ядер — и считать.
AG>Все потоки считают по одинаковому алгоритму, складывают данные (результаты) в общие коллекции.
AG>Вот собственно и все премудрости.

Qt concurrent map


Соглашусь с тем, что вы зря городите зоопарк технологий. Если уж проект на Qt — то используйте Qt. Искать узкие места и альтернативы начнёте когда упрётесь по производительности в реальных условиях.

Здравствуйте, AlexGin, Вы писали:

AG>Доброе время суток, уважаемые коллеги!

AG>Собираюсь делать новый проект на C++, при этом планирую активно
AG>применять распарраллеливание обработки данных за счёт многопоточности.

Как правильно заметили ранее "Преждевременная оптимизация есть корень всех зол".
По опыту скажу выбор Qt оптимален для проектирования кросплатформенного именно ГУИ приложения, он очень своеобразен и сложен, при работе с ним 60% времени уходит на чтения их документации, 30% на гугление и возгласы "сука-идиоты нельзя было написать это сразу", и Только 10% на собственно работу над проектом.
ВинАпи понятен как дважды два и всё отскакивает от зубов, ну для вашего случая порекомендовал бы чистый std либ.
Когда[если] захотите распаралелится там для этого всё есть.

Здравствуйте, Икс, Вы писали:


Икс>По опыту скажу выбор Qt оптимален для проектирования кросплатформенного именно ГУИ приложения,

Делал сервера на Qt. Может, конечно, показаться извратом, но очень сильно упрощает процесс. Из коробки есть интроспекция / рефлексия / базы / строки / многопоточность / кросс-поточные сигналы, COW для любых типов данных, файловая система и т.п. В общем, почти всё что надо. Ну и да, для GUI достаточно удобен.
Не нужно в результате городить зоопарк библиотек.

Икс> он очень своеобразен и сложен, при работе с ним 60% времени уходит на чтения их документации, 30% на гугление и возгласы "сука-идиоты нельзя было написать это сразу", и Только 10% на собственно работу над проектом.

Вопрос опыта. Как и с любым другим фреймворком / платформой / языком. Единственное, что мне не нравится в Qt, так это работа с json-ом. Нет возможностей для удобной генерации. Ну и да, из коробки нет http сервера.

Икс>ВинАпи понятен как дважды два и всё отскакивает от зубов, ну для вашего случая порекомендовал бы чистый std либ.

Только трудозатраты на несколько порядков выше. ВинАпи — это си, а не си плюс плюс. В лучшем случае — "си с классами".