Форум на Исходниках.RU

Распараллеливание выполнения без блокировок

Qraizer — Tue, 25 Feb 2020 12:05:14 +0000

Qraizer:

Цитата JoeUser @ 25.02.20, 01:11

Ну не требует и не требует... Но почему одна и та же студия при указании разных стандартов ведет себя по разному?

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

Распараллеливание выполнения без блокировок

OpenGL — Tue, 25 Feb 2020 04:48:08 +0000

OpenGL:

Цитата JoeUser @ 25.02.20, 01:11

Но почему одна и та же студия при указании разных стандартов ведет себя по разному?

Потому что создатель компилятора поспорил со своим коллегой, что это изменение кодревью пройдёт :D Чисто теоретически ты какой ответ ожидаешь услышать? Такая инициализация это деталь реализации, и она может быть любой, не противоречащей стандарту, что мы и наблюдаем.

Распараллеливание выполнения без блокировок

JoeUser — Tue, 25 Feb 2020 01:11:13 +0000

JoeUser:

Цитата Qraizer @ 23.02.20, 23:37

Вообще достаточно странно

Да нет, я уже спрашивал. Но мне в тупую ответили:

Цитата amk @ 23.02.20, 20:19

Потому что стандарт не требует инициировать переменные на стеке нулём.

amk, извини, но это СТАНДАРТНЫЙ ОТВЕТ от Копетана Очевидность!

Ну не требует и не требует... Но почему одна и та же студия при указании разных стандартов ведет себя по разному?
Я же привел таблицу выше!

Распараллеливание выполнения без блокировок

OpenGL — Mon, 24 Feb 2020 06:44:57 +0000

OpenGL: Вообще достаточно странно, потому что студия на моей памяти в дебаге всегда переменные инициализировала чем-то вроде 0xCCCCCCCC.

Распараллеливание выполнения без блокировок

Qraizer — Sun, 23 Feb 2020 23:37:23 +0000

Qraizer: Та не, просто повезло. Хотя в данном случае, скорее не повезло. 100пудово в прологе main() стоит что-то типа sub esp, XX, где XX суммарный размер локальных переменных, и нули весьма глубоко внутри стека на входе в main() никак от самой main() не зависят.

Распараллеливание выполнения без блокировок

amk — Sun, 23 Feb 2020 20:19:10 +0000

amk:

Цитата JoeUser @ 23.02.20, 19:10

Почему в остальных (с++11, с++14) в дебаге
не нуль

Потому что стандарт не требует инициировать переменные на стеке нулём.

Распараллеливание выполнения без блокировок

Славян — Sun, 23 Feb 2020 19:21:06 +0000

Славян: Ну мож в новых студиях стали очищать стэк. Заботятся. :rolleyes:

Распараллеливание выполнения без блокировок

JoeUser — Sun, 23 Feb 2020 19:10:56 +0000

JoeUser:

Цитата Qraizer @ 23.02.20, 16:56

В дебаге там сразу 0 на стеке

Ну это я уж догадался. Вопрос в другом. Почему в остальных (с++11, с++14) в дебаге
не нуль, а мне только"повезло" с с++17 и только со студийным компилером?
Вот тут мистика.

Распараллеливание выполнения без блокировок

Qraizer — Sun, 23 Feb 2020 16:56:27 +0000

Qraizer: В дебаге там сразу 0 на стеке, в релизе не 0.

Распараллеливание выполнения без блокировок

JoeUser — Sun, 23 Feb 2020 06:23:22 +0000

JoeUser:

Цитата Wound @ 22.02.20, 21:38

На что валидируется? На то что если он не нулевой, то вызвать член через указатель? А расскажи ка, когда он у тебя будет нулевым? В каком месте он у тебя нулевой? Там мусор будет содержатся, и соответственно твоя валидация сработает не так, как ты ожидаешь.

Ты прав.

Цитата Wound @ 22.02.20, 21:38

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

Ты прав.

:blush:

Распараллеливание выполнения без блокировок

JoeUser — Sun, 23 Feb 2020 06:20:38 +0000

JoeUser:

Цитата Wound @ 22.02.20, 21:38

Ты вообще в дебаге наверно запускал, вот у тебя и работало все, или так звезды сошлись, что неинициализированный указатель у тебя оказался 0.

Скорее всего так сошлись звезды :lol: Но это полный песец, и объяснения у меня этому нет.
Да, я с тобой сейчас согласен. Да и ранее, в принципе, с твоей наводки увидел не инициализируемое
поле класса. Но ведь работало - и это меня смущало, что программа должна падать, а она никак и не
падает! И вот утром пришла мысль поэксперементировать с режимами сборки, и вот какая любопытная
табличка у меня вышла:

Сборка	с++11	с++14	с++17
MSVS 2017 Debug x32	-	-	+
MSVS 2017 Release x32	-	-	-
MinGW 7.3.0 Debug x32	-	-	-
MinGW 7.3.0 Release x32	-	-	-

где вылет '-', а норм работа '+'

А у меня как раз все сборки и тесты были под MSVS 2017 Debug x32 с++17

Да, сейчас изменил - добавил инициализацию nullptr

template <typename T>

class FreeStack {

std::atomic<Node<T>*> Head = nullptr; // <---------------- вот тут

public:

И во всех вариантах работа стала нормальной. Получается с MSVS 2017 Debug x32 с++17
какая-то мистика.

Распараллеливание выполнения без блокировок

Wound — Sat, 22 Feb 2020 21:38:45 +0000

Wound:

Цитата JoeUser @ 22.02.20, 08:38

Ты привел дичь, которая не компилируется.

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

Цитата JoeUser @ 22.02.20, 08:38

Все работает.
А в моем коде есть строчка:

И судя по всему ты не увидел в этом коде проблемы. И это пичально.
Не знаю как тебе еще пояснить, тебе и Qraizer и я писал. Но ты не увидел проблемы. Ты вообще в дебаге наверно запускал, вот у тебя и работало все, или так звезды сошлись, что неинициализированный указатель у тебя оказался 0. Короче ладно, пофигу. Когда AV выхватишь в проде, тогда до тебя дойдет в чем у тебя ошибка заключается, а ты ее выхватишь в любом случае рано или поздно.

Цитата JoeUser @ 22.02.20, 08:38

Т.е., как видишь, указатель сперва валидируется, и только если норм берется его значение поля OldHead->Data.
А это ты почему-то проигнорил

Цитата JoeUser @ 22.02.20, 08:38

Так что программа не валится. Но "да", с явной инициализацией вершины будет точнее.

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

Распараллеливание выполнения без блокировок

Qraizer — Sat, 22 Feb 2020 13:22:45 +0000

Qraizer:

Цитата JoeUser @ 21.02.20, 03:35

И нахрена тогда std::shared_ptr раз память все равно течет? Вопросов больше чем ответов.

Потому что у тебя не shared_ptr, а указатель на shared_ptr. Точнее, на Node, внутри которого shared_ptr, неважно.

Добавлено 22.02.20, 13:27

Цитата Pavia @ 21.02.20, 09:33

Это отдельная тема для разговора. Одно описание проблемы займет несколько листов.

Зачем оно нам? Тебе было сложно написать два предложения по-русски, а не тарабарски?

Распараллеливание выполнения без блокировок

OpenGL — Sat, 22 Feb 2020 11:49:44 +0000

OpenGL:

Цитата JoeUser @ 22.02.20, 11:18

В этой проблеме предполагается возможность прерывания и продолжения операций.

Нет, не предполагается. ABA это про ситуацию, когда менеджер памяти выдал указатель на ячейку памяти, которая юзалась ранее, но уже была освобождена. Тогда у тебя появляется шанс на успешный compare_exchange в то время, когда он не должен быть таковым.
И кстати, я только сейчас заметил, что добавление второго читателя или писателя у тебя всё сломает даже безотносительно ABA.

Распараллеливание выполнения без блокировок

JoeUser — Sat, 22 Feb 2020 11:18:20 +0000

JoeUser: OpenGL, прочёл про ABA - это ясно не мой случай. В этой проблеме предполагается возможность прерывания и продолжения операций. У меня же операции атомарные. И я манипулирую адресами, а одинаковое значение указателя не может ссылаться на разные ячейки памяти.

Распараллеливание выполнения без блокировок

OpenGL — Sat, 22 Feb 2020 10:17:59 +0000

OpenGL: Простая задача, он говорил :lol: А ведь ты ещё даже не учитываешь барьеры, не слышал про ABA (которая, кстати, может и не проявится - хз, думать надо) и вообще у тебя пока ещё один читатель и один писатель, что жизнь сильно упрощает :lool:

Распараллеливание выполнения без блокировок

JoeUser — Sat, 22 Feb 2020 10:08:43 +0000

JoeUser:

Цитата Wound @ 21.02.20, 06:15

Если первый поток успел вызвать Pop раньше, чем второй Push то во второй строке будет AV:

Похоже что оч редко (именно в момент переключения потоков), но потенциально может.
Буду это изучать - по идее должно как-то помочь в данной ситуации :whistle:

Распараллеливание выполнения без блокировок

JoeUser — Sat, 22 Feb 2020 08:38:54 +0000

JoeUser:

Цитата Wound @ 21.02.20, 06:15

Ради понимания, попробуй создать консольное приложение и набери там, ну либо просто внимательно взгляни на этот код:

Ты привел дичь, которая не компилируется.

Я твой код немного исправил, чтобы был как-то похож на мой и чтобы компилировался и исполнялся:

#include <iostream>

#include <memory>

#include <atomic>

using namespace std;

template <typename T>

struct Node {

std::shared_ptr<T> Data;

Node* Next;

Node(T const& iData): Data(std::make_shared<T>(iData)) {

std::cout << "Node start" << std:: endl;

}

~Node() {

std::cout << "Node stop" << std:: endl;

}

};

int main() {

std::atomic<Node<std::string>*> Head;

Node<std::string>* OldHead = Head.load();

if (OldHead) std::cout << OldHead->Next;

}

Все работает.
А в моем коде есть строчка:

return OldHead ? OldHead->Data : std::shared_ptr<T>();

Т.е., как видишь, указатель сперва валидируется, и только если норм берется его значение поля OldHead->Data.
А это ты почему-то проигнорил :-?

Хотя, все равно, код не одинаковый. Мою прогу сколько раз не запускал - сбоя ни разу (вообще ни разу) не было.
Буду разбираться, где же и почему "мне повезло".

Добавлено 22.02.20, 08:53

Цитата OpenGL @ 21.02.20, 06:22

если звёзды не сошлись, из-за aba проблемы

Можно подробнее, а что это за "aba проблема"?

Добавлено 22.02.20, 09:10
Немного исправил код Run()

void Run() {

Node<std::string>* Tmp = Stack.Head.load();

std::cout << Tmp << std::endl;

И прогнал под отладкой - Tmp получает nullptr
А как я уже писал выше, у меня Pop() работает с проверкой

return OldHead ? OldHead->Data : std::shared_ptr<T>();

Так что программа не валится. Но "да", с явной инициализацией вершины будет точнее.

Добавлено 22.02.20, 09:22

Цитата Qraizer @ 20.02.20, 18:27

Ещё мне не нравится, что твой Pop() может вернуть ошибку посредством пустого shared_ptr. Придётся везде проверки пихать. Но с фрилуком иначе, боюсь, и не получится.

Вечером попробую тест поставить - вообще ничего не ложить в стек, а в цикле пробовать все время брать из пустого. Ну и запущу под Линухом под Valgrind'ом.

Распараллеливание выполнения без блокировок

Pavia — Fri, 21 Feb 2020 09:33:46 +0000

Pavia:

Цитата Qraizer @ 20.02.20, 12:49

Цитата Pavia @ 19.02.20, 22:35

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

Цитата Pavia @ 20.02.20, 01:22

Я вам рассказал про подводные камни. А что с ними делать это вам решать.

Этих фраз даже я не понял. Набор слов. Pavia, попрошу быть конкретнее, чтобы тебя можно было понимать по-русски. Так что, увы, не рассказал.

Это отдельная тема для разговора. Одно описание проблемы займет несколько листов. Только потому что Вы не подготовлены, а терминология в данной области оставляет желать лучшего.И ещё столько же описание корня проблемы.

Тест я год назад делал вот выложен:
https://www.programmersforum.ru/showthread.php?t=328066

Сейчас я в командировке и сделать скриншоты с бинарником и отладчиком не получится... Судя по коду это вариант с 1 Юнитом. А так для полной демонстрации нужно сделать 2-х агентов для наглядности.

PS. Постараюсь на следующей неделе сделать.

Распараллеливание выполнения без блокировок

OpenGL — Fri, 21 Feb 2020 06:22:01 +0000

OpenGL: А вообще по-моему у тебя тут есть риск вытащить один и тот же элемент дважды, если звёзды не сошлись, из-за aba проблемы. Да, вероятность мала, но тем не менее

Распараллеливание выполнения без блокировок

JoeUser — Fri, 21 Feb 2020 06:15:41 +0000

JoeUser:

Цитата OpenGL @ 21.02.20, 06:06

Сам-то не видишь тут противоречия?

Противоречие одно - эти механизмы нечасто были использованы. А ведь кода совсем мало.
Поэтому и столько обсуждений. А не потому, что тут что-то из ряда вон громоздкое и
сложное. ИМХО.

Распараллеливание выполнения без блокировок

Wound — Fri, 21 Feb 2020 06:15:07 +0000

Wound:

Цитата JoeUser @ 20.02.20, 18:40

Освобождений не было. Изменил код:

Я если честно так и не увидел - где ты изменил код? У тебя как было AV, так оно и осталось ровно в том же месте.
Если первый поток успел вызвать Pop раньше, чем второй Push то во второй строке будет AV:

Node<T>* OldHead = Head.load();

while (OldHead && !Head.compare_exchange_weak(OldHead, OldHead->Next)); //! <<<<< Тут бьудет Access Violation, конкретно на вот этой конструкции - OldHead->Next

Пропустил или забыл что ли?

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

template <typename T>

struct Node {

std::shared_ptr<T> Data;

Node* Next;

Node(T const& iData): Data(std::make_shared<T>(iData)) {

std::cout << "Node start" << std:: endl;

}

~Node() {

std::cout << "Node stop" << std:: endl;

}

};

int main()

{

std::atomic<Node<T>*> Head;

Node<T>* OldHead = Head.load();

std::cout << OldHead->Next->Data; //! <<< Вот тут ошибка, и у тебя ровно такая же.

}

Распараллеливание выполнения без блокировок

OpenGL — Fri, 21 Feb 2020 06:06:10 +0000

OpenGL:

Скрытый текст

Цитата JoeUser @ 20.02.20, 17:06

А нафига? У меня же тривиальнейший случай.

Собственно, чтд - ты просто не читаешь, что тебе пишут :yes: "Нафига" и я, и Киля, и Qraizer объясняли уже несколько раз.
Да и "тривиальнейший случай", который разбирается тут уже пять страниц (три, если вычесть срач) это отдельный прикол. Сам-то не видишь тут противоречия? :jokingly:

Цитата JoeUser @ 21.02.20, 03:35

Может из стека снимать ноду нужно как-то иначе? А-ля в стиле std::move?

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

Распараллеливание выполнения без блокировок

JoeUser — Fri, 21 Feb 2020 03:35:36 +0000

JoeUser: И нахрена тогда std::shared_ptr раз память все равно течет? Вопросов больше чем ответов.
Может из стека снимать ноду нужно как-то иначе? А-ля в стиле std::move?

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 18:40:02 +0000

JoeUser: Wound, Qraizer, косяк с утечкой всеж был.
И Киля, спасибо за наводку!

Я зачекал, изменил вот так:

template <typename T>

struct Node {

std::shared_ptr<T> Data;

Node* Next;

Node(T const& iData): Data(std::make_shared<T>(iData)) {

std::cout << "Node start" << std:: endl;

}

~Node() {

std::cout << "Node stop" << std:: endl;

}

};

Освобождений не было. Изменил код:

template <typename T>

class FreeStack {

std::atomic<Node<T>*> Head;

public:

void Push(T const& iData) {

Node<T>* const NewNode = new Node<T>(iData);

NewNode->Next = Head.load();

while (!Head.compare_exchange_weak(NewNode->Next, NewNode));

}

std::shared_ptr<T> Pop() {

Node<T>* OldHead = Head.load();

while (OldHead && !Head.compare_exchange_weak(OldHead, OldHead->Next));

if (OldHead) {

auto Ret = OldHead->Data;

delete OldHead; // <---------------------- тут

return Ret;

} else

return std::shared_ptr<T>();

}

};

А вот теперь все ровно! Что выделяется, то потом и освобождается.

Добавлено 20.02.20, 18:43
Хотя, странно :-? push() и pop() я взял из книжки чисто почти копипастой.
Неужели не проверяют, что пишут ...

Добавлено 20.02.20, 19:19
И кстати, да - вопрос к автору книжки, этому Уильямсу ... Если есть такой
жесткий косяк с утечкой памяти, то что остального полезного можно получить
из раздела о lock-free структурах, кроме как упоминания полезного метода
std::atomic::compare_exchange_weak?

:-?

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 18:27:17 +0000

Qraizer:

std::shared_ptr<T> Data;

Node(T const& iData): Data(std::make_shared<T>(iData)) { }

Node<T>* const NewNode = new Node<T>(iData);

new выделяет память и конструирует на ней iData. Если что-то пойдёт не так, память освободится. Что может пойти не так? Конструктор Node делает make_shared, который потенциально выделяет память, т.к. конструирует shared_ptr<>. Если что-то пойдёт не так, в частности из-за конструктора копии T aka iData, это проблемы make_shared(), чтобы не допустить утечек. По-любому это будет конструктор Node, так что мимо внимания new сие не пройдёт. Конструктор копии shared_ptr имеет атрибут nothrow, и тем более его имеет перемещающий конструктор, который будет задействован в твоём случае. Что не удивительно ни разу, но убедиться было не лишним.
При неуспешном создании NewNode все проблемы локализованы внутри new. После успешного создания NewNode остальные операции nothrow. Откуда утечки?

Добавлено 20.02.20, 18:36
Ещё мне не нравится, что твой Pop() может вернуть ошибку посредством пустого shared_ptr. Придётся везде проверки пихать. Но с фрилуком иначе, боюсь, и не получится.

Добавлено 20.02.20, 18:38
P.S.

Цитата Qraizer @ 20.02.20, 18:27

Откуда утечки?

Если там намёк на отсутствие деструктора у стека, то это уже другой вопрос.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 18:23:14 +0000

Wound:

Цитата JoeUser @ 20.02.20, 16:43

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

Угу, конечно, я тебе на этот косяк указал еще раньше. Но ты почему то начал обвинять меня в том, что я строю из себя шибко умного. :-?

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 18:10:29 +0000

Qraizer: А на что тогда, по-твоему, std::shared_ptr<> нужен? Накой кому нужен просто абстрактный счётчик копий?

Добавлено 20.02.20, 18:15

Цитата JoeUser @ 20.02.20, 16:36

Вот. То что я просил. Согласен и исправлю. Но пока не понял почему эта переменная инициализируется нулями. За все попытки запуска ни разу не сбойнуло. Странно.

Ну, тебе на это ещё Wound указал до меня. А так-то атомики без явной инициализации инитятся дефолтом, т.е. никак.

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 17:06:24 +0000

JoeUser:

Цитата OpenGL @ 20.02.20, 16:35

Спросил только, почему не взял/скопипастил известную lock-free библиотеку (мало ли, вдруг не знает её)

А нафига? У меня же тривиальнейший случай.

Кстати, на счет советов с мьютексами для моего случая - я это воспринимаю примерно так:

if (а == 1) {

// на всякий случай, чтобы уж точно

if (а == 1) {

b=1;

break;

}

Можно и так. Только зачем.

Добавлено 20.02.20, 17:27

Цитата Wound @ 20.02.20, 13:00

И где этот хваленный RAII ?

Хваленого RAII нет, но за место возможной утечки - сенкс. Действительно, часть кода не моя,
с книжки. И у меня тоже возник вопрос - new есть, а delete нету. Разве только что это не
обеспечивается std::shared_ptr :-?

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 16:48:57 +0000

JoeUser:

Цитата Qraizer @ 20.02.20, 14:22

А теперь у тебя двусвязный список.

Это я понимаю! Есть структуры (мой случай), когда free-lock реализуется просто и на ура. А есть структуры, тот же двусвязный список, где это реализовать невозможно или крайне затруднительно. В моем вопросе - мне просто повезло.

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 16:43:29 +0000

JoeUser:

Цитата OpenGL @ 20.02.20, 16:35

неумения читать чужие аргументы

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

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 16:36:56 +0000

JoeUser:

Цитата Qraizer @ 20.02.20, 12:46

Как минимум не инициализировал FreeStack::Head.

Вот. То что я просил. Согласен и исправлю. Но пока не понял почему эта переменная инициализируется нулями. За все попытки запуска ни разу не сбойнуло. Странно. :-?

Цитата ЫукпШ @ 20.02.20, 11:43

Вставил 2 карт-ридера и скопировал с одной карты на другую.

Ну это явно не мой вариант! У меня читаются только карточки с магнитной полосой, вмещающие сотни байт, даже не килобайты. Это примерно тоже самое, если к компу подключить вторую клавиатуру. Можно. Только бессмысленно.

Цитата Qraizer @ 20.02.20, 12:46

Неперехваченное исключение прибьёт всё приложение. Если это не устраивает, то нужно как-то хендлить.

Скорее всего так и есть. По идее любой new нужно оборачивать в try-catch (а вдруг памяти не хватит), но на практике мало кто это делает. В моем реальном (не синтетическом) случае тож скорее всего исключений не будет, я не вижу где.

Цитата Qraizer @ 20.02.20, 12:46

Юзеру с головой достаточно 100мс реакции

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

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 16:35:01 +0000

OpenGL:

Цитата Qraizer @ 20.02.20, 15:39

Это его дело.

Я с этим и не спорил изначально. Спросил только, почему не взял/скопипастил известную lock-free библиотеку (мало ли, вдруг не знает её), а с ТЗ и выбранным способом решения пусть сам разбирается. Кто я, в конце-концов, такой, чтобы мешать усложнить ТС себе жизнь? :D Но вот это:

Цитата JoeUser @ 20.02.20, 09:16

Вот пошла тема!!! Рациональность. Прекрасненько. Тут есть о чем поговорить. Расскажи мне, пожалуйста, как сделать рациональнее!

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

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 15:39:21 +0000

Qraizer:

Цитата OpenGL @ 20.02.20, 14:58

Речь о том, что ТС предпочёл сложное решение простому при отсутствии хоть каких-либо предпосылок к тому, что сложное окажется эффективнее. Это примерно как писать сортировку вставками, не произведя замеры и не убедившись, что std::sort в данном случае окажется хуже.

Это его дело. Давайте не будем, как любят цитировать по поводу русских форумов, отвечать человеку на не заданные вопросы. Мне понадобился всего абзац чётких фактов вместо трёх страниц вокруг да около, дальше пусть решает сам. И кстати, задача у него действительно пока проста – управление одной переменной.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 15:12:10 +0000

Wound:

Цитата Qraizer @ 20.02.20, 14:22

Да. Если new или даже new[], успешно распределили память, но в конструкторе одного из объектов произошёл бадабум, то все уже сконструированные объекты, как и положено, удаляются и выделенная new или new[] память освобождается.

Вообще-то в его коде другая ситуация. Не та о которой говоришь ты.

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 14:58:20 +0000

OpenGL:

Цитата Qraizer @ 20.02.20, 13:56

Я тоже, к примеру, не буду оборачивать в смарт какой-нибудь поинтер на что-либо, который всего лишь нужно передать куда-то в legacy API как константу.

Я не понял, к чему этот пример. Речь о том, что ТС предпочёл сложное решение простому при отсутствии хоть каких-либо предпосылок к тому, что сложное окажется эффективнее. Это примерно как писать сортировку вставками, не произведя замеры и не убедившись, что std::sort в данном случае окажется хуже.

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 14:22:59 +0000

Qraizer: JoeUser, фрилок очень занятная и полезная штука. Но ты должен понимать, что оно лишь обеспечивает целостность тривиальных операций языка, но никак ничего не охраняет от коллизий. Именно поэтому и придуманы были объекты синхронизации, чтобы будучи реализованными на фрилуках где-то глубоко в своём ядре, дать тебе возможность писать защищённый от коллизий код произвольной сложности. Без них ты сам должен это делать. Захватывать объект, для чего использовать спинлук, и в итоге собрать свой собственный объект. Тот самый, использования которого хотел избежать. Вот у тебя и спрашивают, а зачем оно тебе? Непонятно только, почему таким заумным способом спрашивают. Очень редко бывает, когда достаточно просто атомарно сделать что-то тривиальное. Ну вот у тебя это манипуляция Next, например. Ну ок. А теперь у тебя двусвязный список. А у него два поинтера. Ну-ка представь себе атомарное изменение двух поинтеров. Как ты себе это представишь иначе, кроме как булевый флаг, который спинится на "занят"/"свободен" и под "занят" менять, причём уже без всяких атомиков (хотя и с барьерами). И чем тебе этот флаг не мьютекс тогда? Представь теперь что тебе не надо менять, а надо просто пройти по этому списку. Без подобного булевого флага обойдёшься? Точно? Уверен?
Использование принципов фрилок сродни "я сам всё знаю и за всем слежу". Есть любители нативных поинтеров или там ручного управления ресурсами. В ряде случаев оно даже бывает оправдано. Главное тут – чуять грань. Попробуй вместо одной нитки у себя в примере завести несколько. Почувствуй т.с. руками, каково это.

Добавлено 20.02.20, 14:26

Цитата Wound @ 20.02.20, 14:14

И когда это new - гарантировал отсуствие утечек? Память он выделил, а дальше в методе вылазиит исключение - и что это гарантирует отсуствие утечек памяти?

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 14:14:41 +0000

Wound:

Цитата Qraizer @ 20.02.20, 13:56

Создание объекта new гарантирует отсутствие утечек. Операции с атомиками там бессбойные. Операции с сырым поинтером бессбойные. Проблем не ожидается.

Сбойные, как минимум в Pop методе, в указателе может быть мусор, из за чего полетит AV при вызове - OldHead>Next

Добавлено 20.02.20, 14:15
И когда это new - гарантировал отсуствие утечек? Память он выделил, а дальше в методе вылазиит исключение - и что это гарантирует отсуствие утечек памяти? В С++ GC завезли или я что то пропустил?

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 13:56:36 +0000

Qraizer:

Цитата OpenGL @ 20.02.20, 09:58

Цитата JoeUser @ 20.02.20, 09:43

Мусье, а вы бы мне могли обосновать необходимость блокировки, где и без нее можно обойтись?

Звучит примерно как "обоснуй необходимость компилятора, ведь можно в hex кодах всё написать". Можно, конечно, просто это сложно. lock free алгоритмы в разы более сложные в написании и отладке, да ещё и далеко не всегда они работают быстрее (по-моему очередь и стек так вообще часто медленней оказываются, чем с блокировкой), так что в данном случае всё наоборот - ты должен обосновать необходимость реализовывать с lock-free. У тебя есть замеры времени в реальных условиях, из которых следует, что ты много времени тратишь на на ожидания в мьютексах? Или может быть твоя основная цель это научиться работать с lock-free? Если ответа на оба вопроса "нет", то твоё решение менее рационально, чем решение с блокировками.

Нет. Я тоже, к примеру, не буду оборачивать в смарт какой-нибудь поинтер на что-либо, который всего лишь нужно передать куда-то в legacy API как константу. Если что-то можно сделать просто, это нужно делать просто. В hex набирать программу всегда непросто... хотя бывают гурманы.

Добавлено 20.02.20, 13:55

Цитата Wound @ 20.02.20, 13:00

OpenGL, ты мне помнится доказывал что в С++ утечек нет. Узри:

Цитата Wound @ 20.02.20, 12:29

Node* const NewNode = new Node(iData); //! <<< Выделение памяти

И где этот хваленный RAII ? И вот такого кода тонны по всюду.
У него в Попе стэка или в том же пуше, после выделения памяти произойдет исключение - и утечка ресурса гарантирована.

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 13:07:21 +0000

Qraizer: А пока людям, которые думают, что классический подход к многопоточности устарел, предлагаю просветиться вот тут. Очень занятное чтиво. Будет чем пока заняться.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 13:00:48 +0000

Wound: OpenGL, ты мне помнится доказывал что в С++ утечек нет. Узри:

Цитата Wound @ 20.02.20, 12:29

Node* const NewNode = new Node(iData); //! <<< Выделение памяти

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 12:49:08 +0000

Qraizer:

Цитата Pavia @ 19.02.20, 22:35

Цитата Pavia @ 20.02.20, 01:22

Я вам рассказал про подводные камни. А что с ними делать это вам решать.

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 12:48:48 +0000

OpenGL:

Цитата JoeUser @ 20.02.20, 11:27

а стараюсь оперативно решать текущие вопросы.

Выдать сложный алгоритм вместо простого без малейших обоснований того, что простой будет работать так же эффективно это что угодно, но не "оперативное решение текущих вопросов".

Распараллеливание выполнения без блокировок

Qraizer — Thu, 20 Feb 2020 12:46:22 +0000

Qraizer:

Цитата JoeUser @ 19.02.20, 13:58

1) Где какие ошибки я допустил?

Как минимум не инициализировал FreeStack::Head.

Цитата JoeUser @ 19.02.20, 13:58

2) В каких местах имеет смысл ловить и обрабатывать исключения?

Не надо. Слишком простой пример. В целом если, конечно любую стартовую функцию потока нужно рассматривать наравне с main(). У тебя это WriterThread::operator()(). Неперехваченное исключение прибьёт всё приложение. Если это не устраивает, то нужно как-то хендлить.

Цитата JoeUser @ 19.02.20, 13:58

3) По скольку отдельная нить не заточена на вычисления, а скорее на ожидания - какой интервал опроса имеет смысл оставить, чтобы попусту не грузить систему?

Ну блин. Кто ж помимо тебя на это ответит-то? Зависит от задачи. Юзеру с головой достаточно 100мс реакции, процессам реального времени и 1мс может оказаться много.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 12:29:26 +0000

Wound: Добрался до компа, давай еще раз:

Цитата JoeUser @ 20.02.20, 11:15

Если стек не пуст - pop() вернет последний OldHead->Data или пустой std::shared_ptr(), если стек пуст;

Причем тут что вернет pop?
Я спрашивал:

Цитата Wound @ 20.02.20, 10:58

Чему будет равно значение переменной OldHead в Pop'e если стек пустой?

Теперь на пальцах:

template <typename T>

class FreeStack {

std::atomic<Node<T>*> Head; //! <<< Голый указатель обернутый в std::atomic

public:

void Push(T const& iData) {

Node<T>* const NewNode = new Node<T>(iData); //! <<< Выделение памяти

NewNode->Next = Head.load(); //! <<<< Что тут вернет load, если стек пустой???? nullptr ??? Ты уверен в этом? :D

while (!Head.compare_exchange_weak(NewNode->Next, NewNode));

}

std::shared_ptr<T> Pop() {

Node<T>* OldHead = Head.load(); //! <<<< Что тут вернет load, если стек пустой ???? nullptr ??? Ты уверен в этом? :D

while (OldHead && !Head.compare_exchange_weak(OldHead, OldHead->Next)); //! <<< Тут идет проверка что если OldHead не nullptr - что то сделать,

//! в частности если память для OldHead выделена не была(а вызов pop легко может быть вызвон до push), и при этом OldHead не равен nullptr, Грохнется вот тут -> OldHead->Next <<< Access Violation

return OldHead ? OldHead->Data : std::shared_ptr<T>();

}

};

Так понятнее ?

Я лично не вижу нигде в этом коде где бы Head'у или NewNode->Next'у выставлялся nullptr. Или по стандарту неинициализированные указатели у нас всегда равны nullptr?

Добавлено 20.02.20, 12:41

Цитата JoeUser @ 20.02.20, 11:33

Но, по-моему, ты считаешь себя умнее Энтони Уильямса.
При всем моем уважении к тебе - я уверен, ты себя
переоцениваешь.

Речь идет о твоем коде вообще то, а про Энтони Уильямса.

Распараллеливание выполнения без блокировок

ЫукпШ — Thu, 20 Feb 2020 11:43:49 +0000

ЫукпШ:

Цитата JoeUser @ 20.02.20, 11:27

Но по теме ... не представляю, зачем на компе 2 и более одинаковых кард-считывателя. У меня моск разрушается!

Это легко !

Скрытый текст

Очень люблю почитать.
У меня в электронной книге стоит карточка с личной подборкой - очень много
уже, гигабайт 10 скопилось.
Понадобилось/захотелось сбросить копию на другую карточку.
Вставил 2 карт-ридера и скопировал с одной карты на другую.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 11:42:05 +0000

Wound:

Цитата JoeUser @ 20.02.20, 11:33

Это метод std::atomic ващето! Ты чего там? ку-ку??

Да неужели. Перечитай ещё раз мой пост выше. Я даже тебе комментарии к проблемным участкам написал

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 11:33:31 +0000

JoeUser:

Цитата Wound @ 20.02.20, 11:30

Давно у shared_ptr метод load появился?

Это метод std::atomic ващето!censored

Добавлено 20.02.20, 11:38

Цитата Wound @ 20.02.20, 11:30

Тебе только кажется что оно работает.

Ну запили тесты, я прогоню все что скажешь.

Но, по-моему, ты считаешь себя умнее Энтони Уильямса.
При всем моем уважении к тебе - я уверен, ты себя
переоцениваешь.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 11:30:22 +0000

Wound:

Цитата JoeUser @ 20.02.20, 11:15

Если стек не пуст - pop() вернет последний OldHead->Data или пустой std::shared_ptr(), если стек пуст;

Давно у shared_ptr метод load появился?

Цитата JoeUser @ 20.02.20, 11:15

.е я как-то написал, он работает, и я не разобрался, и ты кросава?
Зашибись логика!

Тебе только кажется что оно работает.

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 11:27:27 +0000

JoeUser: ЫукпШ, у меня лишь одно оправдание - я не стараюсь предугадывать будущее, а стараюсь оперативно решать текущие вопросы. И решать максимально быстро. Другой вопрос "а качественно ли?". Стараюсь качественно. Но приоритет - сроки, потом качество. И да, грешен, иногда приходится говнокодить.

Но по теме ... не представляю, зачем на компе 2 и более одинаковых кард-считывателя. У меня моск разрушается!

Распараллеливание выполнения без блокировок

ЫукпШ — Thu, 20 Feb 2020 11:20:00 +0000

ЫукпШ:

Цитата JoeUser @ 20.02.20, 11:15

Скрытый текст

Цитата ЫукпШ @ 20.02.20, 11:00

Завтра к тебе придут и скажут:

Это вообще оффтоп. Но не скажут - щя получилось так, я являюсь и Заказчиком И Исполнителем.

Скрытый текст

...
На предварительном следствии в полицейском участке на все вопросы он вопил одну и ту же стереотипную фразу:
— У меня писчебумажный магазин!
На что получал такой же стереотипный ответ:
— Это для вас не оправдание.
...

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 11:15:29 +0000

JoeUser:

Цитата Wound @ 20.02.20, 10:58

Чему будет равно значение переменной OldHead в Pop'e если стек пустой?

Если стек не пуст - pop() вернет последний OldHead->Data или пустой std::shared_ptr(), если стек пуст;

Цитата Wound @ 20.02.20, 10:58

Конечно сложен, ты в нем сам даже толком не разобрался

Т.е я как-то написал, он работает, и я не разобрался, и ты кросава? :lol:
Зашибись логика! :jokingly:

Добавлено 20.02.20, 11:17

Скрытый текст

Цитата ЫукпШ @ 20.02.20, 11:00

Завтра к тебе придут и скажут:

Это вообще оффтоп. Но не скажут - щя получилось так, я являюсь и Заказчиком И Исполнителем.

Распараллеливание выполнения без блокировок

ЫукпШ — Thu, 20 Feb 2020 11:00:13 +0000

ЫукпШ:

Цитата JoeUser @ 20.02.20, 10:58

Возникает вопрос, зачем мне все выше прочитанное?

Всё просто.
Если возникает такой вопрос, значит и читать не надо.

Добавлено 20.02.20, 11:03

Цитата JoeUser @ 20.02.20, 10:58

А моя цель проста, никаких библиотечных реализаций, все - тупо для проекта.
Никаких "расширений" - только 2 потока, строго 2 потока.

Это только кажется.
Завтра к тебе придут и скажут:
- Ты так классно сделал работу !
Нам понравилось, делай ещё много таких проектов, хороших и нужных.

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 10:58:30 +0000

JoeUser: ЫукпШ, конечно большое спасибо за ответ!
Но, увы, слишком много букв, слишком много ненужных возможностей.
А моя цель проста, никаких библиотечных реализаций, все - тупо для проекта.
Никаких "расширений" - только 2 потока, строго 2 потока.

Возникает вопрос, зачем мне все выше прочитанное?
Возникает второй вопрос, а был ли прочтен вместе с кодом заданный вопрос с первом сообщении?

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 10:58:04 +0000

Wound:

Цитата JoeUser @ 20.02.20, 10:27

Что мой FreeStack так серьезно сложен? Да ладно? Да ладно!

Конечно сложен, ты в нем сам даже толком не разобрался :lol:
Допустим на вскидку:

void Push(T const& iData) {

Node<T>* const NewNode = new Node<T>(iData);

NewNode->Next = Head.load();

while (!Head.compare_exchange_weak(NewNode->Next, NewNode));

}

std::shared_ptr<T> Pop() {

Node<T>* OldHead = Head.load();

while (OldHead && !Head.compare_exchange_weak(OldHead, OldHead->Next));

return OldHead ? OldHead->Data : std::shared_ptr<T>();

}

Чему будет равно значение переменной OldHead в Pop'e если стек пустой?
Вот тут я имею ввиду:

Node<T>* OldHead = Head.load(); //! - вот эта шляпа что тебе возвратит, если стек твой пуст?

while (OldHead && !Head.compare_exchange_weak(OldHead, OldHead->Next)); //! А тут что будет, если тебе возвратит отличное от 0 значение?

Ты с указателями бы разобрался для начала, а уж потом бы lock-free алгоритмы писал.

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 10:50:55 +0000

OpenGL:

Цитата JoeUser @ 20.02.20, 10:27

Что мой FreeStack так серьезно сложен? Да ладно? Да ладно!

Да. Он не сложнее быстрой сортировки, например, но если кто-то будет писать сортировку просто так вместо использования той, что в стандартной библиотеке, мотивируя это тем, что она несложная, то это кто-то просто решает задачу нерационально. Как и ты сейчас.

Распараллеливание выполнения без блокировок

ЫукпШ — Thu, 20 Feb 2020 10:49:15 +0000

ЫукпШ:

Цитата JoeUser @ 20.02.20, 09:16

Вводная: есть GUI процесс, есть процесс, опрашивающий Кардридер в неблокирующем режиме.
В моем синтетическом примере основной процесс = ReaderThread, а процесс опроса Кардридера WriteThread.

Жду более "оптимальный" вариант и конечно же его обоснование!

Не хотелось бы встревать в жёсткую дискуссию..что-то я устал
за последнее время.
Могу просто рассказать, как делал сам.
А в качестве обоснования могу привести наисерьёзнейший аргумент:
"Нутром чую, что правильно - именно так".

Скрытый текст

Итак, есть GUI - приложение с его оконной процедурой.
Есть рабочий поток (или потоки) которые что-то там много делают.
Пусть будет карт-ридер, это неважно. Хоть 10.

1. Смастерим класс-коммуникационный объект, для работы и обмена между
разными потоками. Это будет шаблонный класс.
Его основа - две потоко-безопасные очереди. Разного направления,
условно "туда и обратно". Где хочешь их бери, хоть сам луди.
(а что такое очередь? Это массив, индексы которого рассчитываются по алгоритму очереди)

2. Напишем класс-интерфейс для возбуждения событий.
Назовём его, например, I_RiseEvent. У него будет роутина RiseEvent, которая будет
реализовываться в дочерних классах.

3. Класс нашего главного окна (или любого другого, которого надо)
назначим наследником - того библиотечного класса окна и интерфейса I_RiseEvent.
Множественным наследованием.

4. Тоже самое с нашим рабочим потоком - он наследник базового класса - потока и I_RiseEvent.

5. Инициализация комм-объекта произойдёт после создания объекта рабочего потока и окна.
Дело в том, что объекту коммуникации надо обязательно передать указатели на объекты-интерфейсы
потока и окна. Идея тут простая - когда один из участников обмена засылает
структуру обмена в очередь, автоматически возбуждается событие на принимающей стороне.
А поскольку интерфейс - абстрактен, и реализация возбуждения события происходит
в конкретном объекте конкретного класса проекта, значит наш коммуникационный объект
от проекта вообще не зависит. Это прекрасно, и мы можем включить такой класс
в библиотеку и пользоваться проверенным решением во всех проектах.
Поскольку наш коммуникационный объект (и используемые им очереди) мы сделаем
шаблонным классом. А значит, пригодным для работы с любыми типами данных.

6. как всё работает - допустим юзер щёлкнул по кнопке - обработчик кнопки заполнил
структуру с запросом, занёс её в коммуникационный объект в направлении "туда".
Сам факт занесения вызвал процедуру "RiseEvent" у объекта-потока.
Эта процедура подожгла семафор.
Семафор разбудил поток, который мирно спал на Wait-процедуре.
Поток запустил обработчик работы/опроса чего надо. Допустим, карт-ридера.
Через некоторое время (а главному окну всё это пофигу) операция завершилась.
Как-то. Обработчик потока записал результаты в какую-то там (заранее изобретённую)
структуру и заслал в коммуникационный объект в очередь "обратно". Сам факт записи в очередь
вызвал процедуру "RisEvent" уже главного окна. Чтобы не работать в контексте
рабочего потока, окно пошлёт само себе асинхронное, заранее предусмотренное
сообщение.
Получив сообщение, обработчик окна этого сообщения извлечёт из очереди структуру
с результатом... и у юзера в строке статуса (например) появится сообщение -
"Операция такая-то завершилась успешно"

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

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

Привожу пример - получаем по сети данные и строим график.
1-й рабочий поток непосредственно работает с сетью, получает данные,
проверяет, преобразовывает, засылает в комм-объект, засыпает.
2-й рабочий поток-графопостроитель. Получает данные 1-го, просыпается,
начинает рисовать, результат засылает в комм-объект (другой уже) засыпает.
3-й поток - главного окна. Возбуждение события приведёт к извлечению картинки
и перерисовке ею главного окна.
Однако, графопостроитель - приёмник запросов не от одного комм-обекта.
Он должен получать данные от главного окна :
- при измерении размеров окна
- при изменении графических параметров - цветА, фонты, вид гафика, их количество итд.
Все, что можно назвать "формой представления".
И поток-графопостроитель действительно будет выполнять все эти запросы от 3-х источников
последовательно и слать результат одному приёмнику (в виде картинки главному потоку).

При этом работа отдельных частей приложения максимально абстрагирована
от других частей приложения. Структура приложения становится полностью асинхронной,
никто-никого-никогда не ждёт.
Свою работу сделал, сунул результат в очередь и всё.
Дальнейшая судьба данных не волнует.
Конвейер.

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

Как-то так.

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 10:27:44 +0000

JoeUser:

Цитата OpenGL @ 20.02.20, 09:58

Разжёвывать очевидную мысль, да ещё оффтопя, мне не интересно.

Я немного гиперболизирую, несколько в обход вежливому общению. Просто представь, ты пишешь утверждение типа:
censored.

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

Цитата OpenGL @ 20.02.20, 09:58

Звучит примерно как "обоснуй необходимость компилятора, ведь можно в hex кодах всё написать".

Что мой FreeStack так серьезно сложен? Да ладно? Да ладно!
Есть другое мнение. Для компиляции Хэллоу Ворлда не нужно ставить lcc (в 624KB), а нужно ставить вcю студию в более чем 11GB. Зачем?
ДА НА ВСЯКИЙ СЛУЧАЙ !!! Прекрасная логика!

ПРЕСНАЯ ВОДА ПО ПРЕЖНЕМУ detected!
В первой теме код и вопросы. Это тема.

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 09:58:22 +0000

OpenGL:

Цитата JoeUser @ 20.02.20, 09:43

Не понял тебя. Атомарные операции гарантируют "единоличный" доступ/операции. Считывание, обмен... Ты о каком смысле вообще?

Ну перечитай ещё раз :-? Разжёвывать очевидную мысль, да ещё оффтопя, мне не интересно.

Цитата JoeUser @ 20.02.20, 09:43

Мусье, а вы бы мне могли обосновать необходимость блокировки, где и без нее можно обойтись?

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 09:43:16 +0000

JoeUser:

Цитата OpenGL @ 20.02.20, 09:31

Тогда ты просто сам не понял, что сказал, потому что в этом контексте фраза "чтобы инварианты из STL выполнялись." теряет смысл.

:blink:

Не понял тебя. Атомарные операции гарантируют "единоличный" доступ/операции. Считывание, обмен... Ты о каком смысле вообще?

Цитата OpenGL @ 20.02.20, 09:31

Мсье знает толк, однако. Чем тупое решение с блокировкой не устроило-то?

Мусье, а вы бы мне могли обосновать необходимость блокировки, где и без нее можно обойтись?
И еще, мусье, вы немножко знакомы с тезисом Уильяма из Оккамы ("Бритва Оккамы"), и если "да",
спросите себя - нахрена городить огород? Я имею ввиду- блокировками, если и без них все
прекрасно?

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 09:31:01 +0000

OpenGL:

Цитата JoeUser @ 20.02.20, 09:16

Я про атомарные операции библиотеки... Они и гарантируют инварианты.

Цитата JoeUser @ 20.02.20, 09:16

Вводная: есть GUI процесс, есть процесс, опрашивающий Кардридер в неблокирующем режиме.

У тебя там lock-free контейнеры при межпроцессном взаимодействии? :D Мсье знает толк, однако. Чем тупое решение с блокировкой не устроило-то?

Добавлено 20.02.20, 09:32
По-моему тут что-то из разряда "если в руках молоток, то всё кажется гвоздями"

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 09:16:41 +0000

JoeUser:

Цитата OpenGL @ 20.02.20, 08:58

Какие инварианты и как их нарушает решение с блокировкой?

"Перпендикулярный" вопрос ващето! Я про атомарные операции библиотеки... Они и гарантируют инварианты.
"Решения с блокировкой" - это вами навязываемая шляпа, к которой я в данном треде никакого отношения не имею.

Цитата OpenGL @ 20.02.20, 08:58

Хочешь делать нерационально - дело твоё, мне-то что?

Вот пошла тема!!! Рациональность. Прекрасненько. Тут есть о чем поговорить. Расскажи мне, пожалуйста, как сделать рациональнее!
Вводная: есть GUI процесс, есть процесс, опрашивающий Кардридер в неблокирующем режиме.
В моем синтетическом примере основной процесс = ReaderThread, а процесс опроса Кардридера WriteThread.

Жду более "оптимальный" вариант и конечно же его обоснование!

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 08:58:16 +0000

OpenGL:

Цитата JoeUser @ 20.02.20, 08:42

Мне надо чтобы инварианты из STL выполнялись.

Какие инварианты и как их нарушает решение с блокировкой?

Цитата JoeUser @ 20.02.20, 08:42

Я вас спросил в первом посте - есть ошибки?

Так я и не спорю. Хочешь делать нерационально - дело твоё, мне-то что?

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 08:56:47 +0000

JoeUser: Тут интересное по теме - Параллельное программирование на С++ в действии.Уильямс
В том числе и по lock-free структурам.

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 08:42:44 +0000

JoeUser:

Цитата OpenGL @ 20.02.20, 08:22

А так оно и есть. С блокировками у тебя всегда есть части кода, гарантированно выполняющиеся одним потоком. Это банально проще отлаживать и куда быстрее писать, чем сидеть и представлять "а вот тут у меня будет переключение контекста, сюда вклинится другой поток и выполнит воон ту фигню" с lock-free. Так что да, решение с блокировками наверняка окажется надёжнее из-за своей простоты.

А мне не надо "надежнее надежного". Мне надо чтобы инварианты из STL выполнялись. И если там есть часть функций/методов которые работают с lock-free структурами, я буду ими пользоваться. Нравится вам это или нет.

Я вас спросил в первом посте - есть ошибки? А вы меня грузите опасениями!!! Мне этого не надо, я это не просил !!!

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 08:35:27 +0000

JoeUser: offtop was censored

Цитата Wound @ 20.02.20, 08:12

Я тебе уже привел хренову тучу аргументов - отказаться от std::thread, тебе этого мало?

Прости, я что-то кроме бла-бла-бла не заметил сути. Перечисли, пожалуйста (ПОЖАЛУЙСТА)!!! еще раз по пунктам. Чем тебе плох std::thread?

Цитата Wound @ 20.02.20, 08:12

потому что у тебя нет блокировок и гарантировать что эта операция потокобезопасная - нельзя

Т.е как я тебя понимаю, если в Стандарте написано, что данная операция из текущей версии STL атомарная - тебе насрать?! Ты этому не доверяешь?

Цитата Wound @ 20.02.20, 08:12

Ты даже постом выше уже признал что std::cout у тебя не потокобезопасен.

Не "даже" а "всего лишь" - ощути разницу! А ты из говно-момента делаешь себе корону. Хотя нет, мелочей нет. Ты тут прав. Это есть косяк и он должен быть запомнен на будущее.

Цитата Wound @ 20.02.20, 08:12

как Pavia, за то что не привел тебе пруфы

А вот на зло тебе и ему не выдам! :lol: Он не просто ограничился "тезисом", а пытался обосновать. А ты, как всегда, с шашкой на-голо в бой. Нихрена не понял, но по ходу разберемся :lol: Киля, не парься - ты на форуме есть, и это клёво! Даже если мы стреляемся из разных барикад :)

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 08:22:51 +0000

OpenGL:

Цитата JoeUser @ 20.02.20, 08:01

Этот аргумент я себе запишу в смартфон!!! Это не должно умереть!

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 08:12:34 +0000

Wound:
offtop was censored

Цитата JoeUser @ 20.02.20, 07:59

Да нет, я желаю на каждый "профессиональный взгляд" иметь кроме бла-бла-бла - что-то подтверждающее. Ну напиши мне строку в моем коде, обоснуй ошибку. Так уже третья моя просьба мимо. Спрашивается, а нахрена твои слова, если по существу не можешь указать где плохо и как лучше? Извини за эмоции.

Я тебе уже привел хренову тучу аргументов - отказаться от std::thread, тебе этого мало? Так а нахрена ты тут тему вообще создал? Комить уже, ёпта. Все там нормалёк, остальные косяки по мере поступления разрулишь.

Цитата JoeUser @ 20.02.20, 07:59

Бинго! Вот этого ДЖВА года ждал! А еще надежнее - записывать параллельно в бумажный журнал.

Конечно надежнее, когда у тебя есть общий ресурс! Потому что все понятно что и где у тебя происходит. Вот тут есть лок - значит ресурс защищен, а вот тут нет лока - значит возможно косяк. В случае с lock-free алгоритмами - косяк тебя может поджидать на каждом шагу, потому что у тебя нет блокировок и гарантировать что эта операция потокобезопасная - нельзя, вернее можно, если углубленно знать всякие ньюансы использования lock-free(но это явно не про тебя). Допустим ты сам не можешь гарантировать что твой код потокобезопасен и не содержит костылей. Банальное переписывание его с блокировками - можно уже гарантировать что код не содержит каких то подводных камней, и что вот в таких то местах - он гарантированно потокобезопасен.

Цитата JoeUser @ 20.02.20, 07:59

А ты почитай-почитай про lock-free структуры. Когда прочитаешь, прочитай еще раз. И только потом ты поймешь, что то, что я процитировал тебя выше - лютая дичь от незнания. Я читаю и учусь, и ты читай.

Ну конечно. Ты даже постом выше уже признал что std::cout у тебя не потокобезопасен.

Цитата JoeUser @ 20.02.20, 08:01

Этот аргумент я себе запишу в смартфон!!! Это не должно умереть!

Конечно запиши, и желательно еще сделай обои на рабочий стол с этим текстом, чтоб не забыть.

offtop was censored

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 08:01:26 +0000

JoeUser:

Цитата Wound @ 20.02.20, 07:31

С блокировками оно надежнее

Этот аргумент я себе запишу в смартфон!!! :lol: :lol: :lol: Это не должно умереть!

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 07:59:35 +0000

JoeUser:
offsop was censored

Цитата Wound @ 20.02.20, 07:31

Ну ты ж отцов то читать не хочешь. Мне тебе сюда всю книгу цитировать или как?

Цитата Wound @ 20.02.20, 07:31

С блокировками оно надежнее, особенно когда у тебя есть расшаренный ресурс

Бинго! Вот этого ДЖВА года ждал! :lol: А еще надежнее - записывать параллельно в бумажный журнал.

Цитата Wound @ 20.02.20, 07:31

Сегодня у тебя один продьюсер и один потребитель. Завтра может быть несколько потребителей, а после завтра - появятся несколько продьюсеров и несколько потребителей.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 07:31:33 +0000

Wound:
offtop was censored

Цитата JoeUser @ 20.02.20, 07:09

What??? Где, покажи в коде!!!

Ну ты ж отцов то читать не хочешь. Мне тебе сюда всю книгу цитировать или как?

Q: читать отцов – это хорошо. Но ради синтетического простого примера тратить время на гугление материалов, их освоение и осознания идей и концепций никто ожидаемо не будет. Если хочешь заинтересовать оппонента, не надо отправлять в поиск не_знаю_куда, с его точки зрения, не_знаю_чего не_знаю_зачем_мне_якобы_нужного.

Цитата JoeUser @ 20.02.20, 07:09

Киля, ну это же говно!!!
Вместо std::cout << "Waiting for a completion of the detached thread..." << std:: endl; я могу написать std::cout << "Waiting for a completion of the detached thread...\n"; это такая мелочь для синтетического примера. Хотя, да, ты тут прав.

Ну так вот внезапно, у тебя может выползти проблема в проде и не только там где std::cout, это просто был пример. И тогда - счастливой тебе отладки.

Цитата JoeUser @ 20.02.20, 07:09

Да, и кстати, анука обоснуй ... если есть возможность реализовать структуры без блокировок, зачем "мне твое иначе" (с блокировками)? Обоснуй профит!

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

Распараллеливание выполнения без блокировок

JoeUser — Thu, 20 Feb 2020 07:09:39 +0000

JoeUser:
censored

Q: оффтоп, JoeUser. К чему тут этот переход на личность?

Цитата Wound @ 20.02.20, 06:38

Плюс ко всему избежать косяков detach/join у потока

What??? :blink: Где, покажи в коде!!!

Цитата Wound @ 20.02.20, 06:38

на самом деле происходит не атомарный вывод на консоль

Цитата Wound @ 20.02.20, 06:38

Цитата

Однако это нестандартные ситуации. В большинстве случаев вы должны выбирать
программирование на основе задач, а не на основе потоков.

Вот тут я с Меерсом согласен! Нах натягивать сову на глобус. Если задача ясна, архитектура ясна, зачем архитектуру плющить под детские примеры С++, если можно С++ использовать в полной мере для реализации задуманной архитектуры. Вопрос риторический, есличо.

Добавлено 20.02.20, 07:11

Цитата OpenGL @ 20.02.20, 06:48

А зачем самому lock-free алгоритмы писать?

А у меня тривиальный стек - так почему бы и нет?
Или лучше обложиться мьютексами ... так сказать - для надежности? :lol:

Добавлено 20.02.20, 07:13

Цитата Wound @ 20.02.20, 06:53

Да это у него не тз такое, это он сам себе втемяшил что надо делать именно так и никак иначе. А теперь говорит - не учи меня писать, я обчитался книг и теперь хочу писать именно так и никак иначе.

Киля, при всем уважении, ты не лучше всегда знаешь что я хочу.
Иногда я хочу лучше чем ты можешь за меня хотеть! 8-)

Добавлено 20.02.20, 07:18

Цитата Wound @ 20.02.20, 06:53

втемяшил что надо делать именно так и никак иначе

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 06:53:26 +0000

Wound:

Цитата OpenGL @ 20.02.20, 06:48

У него изначальное ТЗ - сделать без блокировок, так что cv пролетает мимо.

Распараллеливание выполнения без блокировок

OpenGL — Thu, 20 Feb 2020 06:48:21 +0000

OpenGL: А зачем самому lock-free алгоритмы писать? Поверь, это либо просто и с кучей подводных камней, либо сложно и нетривиально. Куда лучше взять какой-нибудь libcds и юзать lock-free хоть очередь хоть стек хоть map.

Добавлено 20.02.20, 06:50

Цитата Wound @ 20.02.20, 06:38

Упростит немного код и избавит от лишних флагов, которые только запутывают

У него изначальное ТЗ - сделать без блокировок, так что cv пролетает мимо.

Распараллеливание выполнения без блокировок

Wound — Thu, 20 Feb 2020 06:38:48 +0000

Wound:

Цитата JoeUser @ 20.02.20, 05:58

Я код не просто из башки взял. Я изучил книгу Энтони Уильямса "Прараллельное программирование в действии". И "структуры без блокировок" взял оттуда, почти один-в-один, ну или почти, только мои "расширения", скажем так.

Ну да и на пустом месте нафигачил кучу какого то непонятного кода. ИМХО, тут можно сделать более понятно безо всяких флагов.

Цитата JoeUser @ 20.02.20, 05:58

Нахрена мне другая модель параллелизма, к примеру с std::future? Тем более std::future - это ожидание результата асинхронной операции. Но это не мой случай. У меня нет результата асинхронной операции! У меня есть просто асинхронное исполнение второго потока, результаты которого нужно юзать время от времени (по факту готовности)

Ну хотя бы затем, чтобы нормально обрабатывать исключения. Плюс ко всему избежать косяков detach/join у потока, которые имеют место быть, ну и для того, что подход на основе задач - более гибкий, т.к. ты предоставляешь возможность системе самой решить что и как необходимо использовать. Во многих случаях она лучше тебя знает как и что следует юзать.

Цитата JoeUser @ 20.02.20, 05:58

А вот тут не вижу профита совсем. Если у меня неблокируемое ожидание, чем мне поможет std::condition_variable? Да вообще ничем! Будет просто другой синтаксис, но отдача квантов вычисленя CPU при ожидании останется равной. Так нахрена коту баян?

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

Цитата JoeUser @ 20.02.20, 05:58

Киля, я внимательно прочел твой пост. И понял одно - ты меня хочешь притянуть за уши к блокировкам на основе мьютексов. Но, поверь, это не мой вариант. Это и первое, что мне пришло в голову. Но я специально изучил главу "Структуры, свободные от блокировок", чтобы обойтись без локов в угоду атомарным операциям.

Ну ты себе только говоной боли наберешься в последствии. Во первых самый лучше способ уйти от блокировок - это избавится от общих ресурсов. А у тебя они есть.

Цитата JoeUser @ 20.02.20, 05:58

Давай договоримся так, ты указываешь мне как надо делать в моем коде, а указываешь что у меня в потенциале, в моем коде, должно глючить (где и почему). Но не учишь меня жизни сейчас (я сам когда-то если и обломаюсь, то научусь). А я тебе скидываю скан книги Энтони Уильямса "С++ Concurrency in Action" в русском переводе. Только скажи как и куда?

В принципе можешь делать как хочешь. Но я бы на твоем месте все же Майерса почитал. Например:

Цитата

Подход на основе задач обычно превосходит свой аналог на основе потоков, и небольшие
фрагменты кода, с которыми вы встретились выше, показывают некоторые причины этого.
Здесь doAsyncwork дает возвращаемое значение, в котором, как мы можем разумно предположить, заинтересован вызывающий doAsyncwork код. В случае вызова на основе потоков
нет простого способа к нему обратиться. При подходе на основе потоков нет простого способа получить доступ к вызову. В случае же подхода на основе задач это можно легко сделать,
поскольку фьючерс, возвращаемый std : : async, предлагает функцию get. Эта функция get
еще более важа, если doAsyncwork генерирует искючение, поскольку get обеспечивает доступ и к нему. При подходе на основе потоков в случае генераии функцией doAsyncWork
исключения програма аварийно завершается (с помощью вызова std: : terminate).
Более фундаментаьным различием между подходаи на основе потоков и на основе задач является воплощение более высокого уровня абстракции в последнем. Он освобождает
вас от деталей уравления потоками, что, кстати, напомнило мне о необходимости рассказать о трех значениях слова поток (tread) в параллельном программировании на С++

У std::thread - есть косяки с join/detach, по хорошему его нужно оборачивать в класс. Возможно это не твой случай, но все же. Исключения, которые ты не поймал внутри потока - ты больше нигде и никак не сможешь обработать - утечка ресурсов. Используешь ты их примитивно, потому как использование std::thread - обосновано, когда ты хочешь полностью контролировать работу потока вручную! Ты же ее в своем коде никак не контролируешь от слова совсем, даже приоритет не выставляешь.

Цитата JoeUser @ 20.02.20, 06:00

Хм ... Принято!!! Пруф?

Пруф чего именно?
Допустим, вот в этом куске кода:

Цитата JoeUser @ 19.02.20, 13:58

std::cout << "Waiting for a completion of the detached thread..." << std:: endl;

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

Добавлено 20.02.20, 06:44

Цитата JoeUser @ 20.02.20, 06:09

Если не сложно, просто перечисли. А я сравню со своей ситуацией, коснется ли меня оно.

Я тебе перечислю ситуации, когда следует использовать std::thread, так понятней наверно будет, вот из книги Майерса:

Цитата

Тем не менее существуют ситуации, в которых применение потоков
может быть более подходящим. Они включают в себя следующее.
• Вам нужен доступ к API, лежащей в основе реализации потоков. В С++ API паралельных вычислений обычно реализуется с помощью низкоуровневого платформозависимого API, обычно pthreads или Windows Threads. Эти API в настоящее время
предлагают больше возможностей, чем С++. (Например, С++ не имеет понятий приоритетов или родственности потоков.) Для предоставления достуа к API реализации
потоков std : : thread обычно предагает функцию-член nat ive_handle. Така функциональность отсутствует в std : : future (т.е. в том, что возвращает std : : async).
• Вам требуется возможность оптимизации потоков в вашем приложении. Это может произойти, наример, если вы разрабатываете серверно программное обеспечение с известным профилем выполнения, которое может быть развернуто как единственный процесс на машине с фиксированными аппаратными характеристиками.
• Вам требуется реализовать поточную техолоrию, выходящую за рамки API параллельных вычислений в С++, например пулы потоков на платформах, на которых ваши реализации С++ их не предоставляют.
Однако это нестандартные ситуации. В большинстве случаев вы должны выбирать
программирование на основе задач, а не на основе потоков.