Вопрос по многопоточности

cdcodecpp · Регистрация: 04.06.2022

Студворк — интернет-сервис помощи студентам

Здравствуйте, сейчас смотрю книги по многопоточности, возникло несколько вопросов. Почему-то слово "вопрос" нельзя полностью написать в заголовке.

1. Известно, что переменную bool (или int, неважно) может 1 раз записать только 1 поток, остальные только читают, зачем тогда делать её atomic?

2. Улетят ли вызовы notify_one/notify_all вникуда, если они много раз вызваны перед методами, которые ожидают cv?

3. Допустим, есть 5 потоков и есть общий вектор с огромным количеством элементов. Первый поток изменяет только элементы с идексами 0, 5, 10; второй поток - элементы с индексами 1, 6, 11; третий поток - элементы с индексами 2, 7, 12 и т.д. Правильно ли я понимаю, что переброска кэша и связанное с ним замедление программы все равно может происходить, потому что индексы, с которыми работает каждый поток, находятся по соседству?

4. Вот пример потокобезопасной очереди из книги Вилльямса. Зачем при сравнении head с tail в функции get_tail мы используем мьютекс, который тут же перестает блокироваться после того, как мы вышли из функции?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
#include <iostream>
#include <fstream>
#include <ios>
#include <string>
#include <numeric>
#include <map>
#include <vector>
#include <queue>
#include <iterator>
#include <memory>
#include <mutex>
#include <type_traits>
#include <algorithm>
#include <atomic>
#include <thread>
#include <chrono>
#include <cassert>
 
// clang -std=c++2a -m64 -o thread_safe_queue.exe thread_safe_queue.cpp
 
template<typename T> class thread_safe_queue {
private:
    struct node {
        std::shared_ptr<T> data;
        std::unique_ptr<node> next;
    };
    std::unique_ptr<node> head;
    node* tail;
 
    mutable std::mutex m_head;
    mutable std::mutex m_tail;
 
public:
    thread_safe_queue(const thread_safe_queue& ) = delete;
    thread_safe_queue() : head(new node()), tail(head.get()) {}
 
    node* get_tail() const {
        std::lock_guard<std::mutex> lg_tail(m_tail);
        return tail;
    }
 
    bool empty() const {
        std::lock_guard<std::mutex> lg_head(m_head);
        std::lock_guard<std::mutex> lg_tail(m_tail);
        return (head.get() == tail);
    }
 
    std::shared_ptr<T> pop() {
        std::lock_guard<std::mutex> lg_head(m_head);
        if (head.get() == get_tail()) { // why ?
            return std::shared_ptr<T>();
        }
 
        std::shared_ptr<T> res(head->data);
        std::unique_ptr<node> old_head = std::move(head);
        head = std::move(old_head->next);
        return res;
    }
 
    void push(const T new_value) {
        std::unique_ptr<node> q(new node);
        std::lock_guard<std::mutex> lg_tail(m_tail);
        tail->data = std::make_shared<T>(std::move(new_value));
        tail->next = std::move(q);
        tail = tail->next.get();
    }
};
 
int main(int argc, char *argv[]) {
    return 0;
}

@Aledveu · 03.08.2025, 21:02

Сообщение от Igor3D

Без atomic остальные могут прочитать старое значение, даже если запись (другим потоком) уже свершилась

Это для какой архитектуры ? уж очень интересно.

Сообщение от Igor3D

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

Вот мне реально интересно сравнить. Раз у вас не получилось с lock-free не могли бы вы код показать.

cdcodecpp, за всё обсуждение так и не понятно что у вас за задача.

cdcodecpp · 03.08.2025, 21:22 **[ТС]**

Сообщение от Aledveu

cdcodecpp, за всё обсуждение так и не понятно что у вас за задача.

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

@Aledveu · 03.08.2025, 21:36

Сообщение от cdcodecpp

Я читаю книгу Вильямса и не только её, пытаюсь разобраться с теми вопросами, которые остались для меня непонятными.

попробуйте почитать книжку подревнее - The Little Book of Semaphores
Second Edition
Copyright 2005 Allen B. Downey

там как раз разжевывается теория многопоточности и все типовые и не типовые задачи с примерами и объяснениями.

@Igor3D · 03.08.2025, 22:44

Сообщение от Aledveu

Вот мне реально интересно сравнить. Раз у вас не получилось с lock-free не могли бы вы код показать.

Почему "не получилось"?

В свое время я довольно много (и увлеченно) этим занимался. Но вынужден признать что использование готовых тулзов практичнее и эффективнее. Ну это вечная проблема велик/готовое

Сообщение от Aledveu

cdcodecpp, за всё обсуждение так и не понятно что у вас за задача.

То да.

Сообщение от cdcodecpp

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

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

Сообщение от Aledveu

Это для какой архитектуры ? уж очень интересно.

Да хотя бы для популярной x86_64. Причем известно это давно. В нулевые часто звучали ответы типа

..новое значение будет видимо всеми потоками когда произойдёт синхронизация кешей процессоров..

Типа "легенда о кеше"

В книге Вильямса подробно разбирается поведение для семантики relaxed, да, может прочитаться старое значение, причем даже перезаписанное несколько раз. Гарантируется только "atomicity" (мусора не будет). Полагаю (где это написано - не видел), что поведение для не-атомика точно такое же, т.е. отсутствие всякой синхронизации.

Слушаю Вас, что там Вам "уж очень интересно"?

Добавлено через 23 минуты

Сообщение от Aledveu

попробуйте почитать книжку подревнее - The Little Book of Semaphores
Second Edition
Copyright 2005 Allen B. Downey

Ну, параграф 1.5

But usually some variables are shared among two or more threads; this is one of the ways threads interact with each other. For example, one way to communicate information between threads is for one thread to read a value written by another thread.
If the threads are unsynchronized, then we cannot tell by looking at the program whether the reader will see the value the writer writes or an old value that was already there.

И что не так? Откуда такое горячее желание заорать "Смотрите, смотрите, он этого НЕ ЗНАЕТ!!!"

@Aledveu · 03.08.2025, 23:22

Сообщение от Igor3D

Да хотя бы для популярной x86_64

для х86 всё подробно разжевано в "What Every Programmer Should Know About Memory
Ulrich Drepper Red Hat, Inc."
и про механизмы синхронизации кеша там расписано. но только для х86.
а про другие архитектуры инфу приходится собирать из разрозненных источников. вот мне и интересно.

Сообщение от Igor3D

И что не так? Откуда такое горячее желание заорать "Смотрите, смотрите, он этого НЕ ЗНАЕТ!!!"

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

@Igor3D · 04.08.2025, 01:07

Сообщение от Aledveu

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

Не написано там такого

Сообщение от Igor3D

If the threads are unsynchronized, then we cannot tell by looking at the program whether the reader will see the value the writer writes or an old value that was already there.

Мой перевод

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

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

Добавлено через 36 минут
cdcodecpp, а не написать ли Вам тестовый пример который показывает/доказывает что при отсутствии синхронизации могут быть прочитаны неверные данные? Возможно такое "практическое" изучение будет эффективнее

@Aledveu · 04.08.2025, 11:42

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

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

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

Следующий базовый кирпичик это пул потоков.

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

@gogolik · 04.08.2025, 11:58

Комментарий модератора

cdcodecpp, mashmed135, если будете продолжать свою детскую перепалку - оба отдохнёте от форума. Ближе к теме и повежливее, пожалуйста.

cdcodecpp · 04.08.2025, 12:18 **[ТС]**

Сообщение от Aledveu

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

Он действительно отлавливал не всегда. Но некоторые из тех случаев, с которыми я сталкивался, от отлавливал.

Сообщение от Aledveu

Поэтому чтобы не делать одних и тех же ошибок и не полагаться на санитайзер каждый раз надо написать код который решает вашу задачу и потом только повторно его использовать и не менять.
Например: есть mpmc очередь. Это базовый кирпичи для любой многопоточной программы, да и вообще это очень удобный примитив. Еë один раз написал, протестил (что тоже не тривиально) и больше не прикасается к ней.
Следующий базовый кирпичик это пул потоков.

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

Добавлено через 2 минуты

Сообщение от Aledveu

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

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

Добавлено через 1 минуту

Сообщение от Igor3D

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

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

Алексей1153 · 04.08.2025, 12:42

Сообщение от cdcodecpp

некоторые UB отловить сложно

одно из коварных проявлений UB - когда видимое поведение вроде бы как ожидаемое.

Но рано или поздно всё равно выстрелит

cdcodecpp · 04.08.2025, 21:58 **[ТС]**

Сообщение от Aledveu

попробуйте почитать книжку подревнее - The Little Book of Semaphores
Second Edition
Copyright 2005 Allen B. Downey

Скачал, но она на питоне. Понятно, что принципы похожи, но всё же хотелось бы что-то близкое к C++17.

Добавлено через 2 минуты

Сообщение от Igor3D

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

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

@Igor3D · 05.08.2025, 00:37

Сообщение от Aledveu

Например: есть mpmc очередь. Это базовый кирпичи...
Следующий базовый кирпичик это пул потоков...

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

И что, Вы до сих пор юзаете свою/самописную очередь, пул потоков и.т.п.? Не очень в это верю, как-то на велосипедиста Вы не похожи

Но если так, то чем самопал лучше? И если отвечать честно, то

Да редко, мало случаев когда лучше, чаще хуже

Ну с "пониманием" конечно все хорошо, это светлая сторона любого велика. Но стоит ли оно того?
А если не так, то зачем рекомендовать такой (тернистый) путь? Хотя, как говорили классики

Автор не обязан следовать собственным рекомендациям, они пишутся для других

Сообщение от cdcodecpp

..желательно понять, почему так произошло, а не просто знать, что это происходит.

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

@mashmed135 · 05.08.2025, 08:30

Сообщение от Igor3D

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

Так ты мне приведёшь пример с чтением старого значения после завершения записи из другого потока? Или ты просто пишешь недостоверную информацию?

@Aledveu · 05.08.2025, 12:32

Сообщение от Igor3D

И что, Вы до сих пор юзаете свою/самописную очередь, пул потоков и.т.п.?

какую вы используете?

@Igor3D · 05.08.2025, 17:52

Сообщение от Aledveu

какую вы используете?

Отвечаете вопросом на вопрос

Ладно, много чего использую, часто выбор не мой а используемой либы. Конкретный пример: QThreadPool. Осваивается за полчаса без всякой подготовки. Простое и удобное использование, "кидаем в мешок" задачи, пул ими займется. Потом waitForDone, все посчитано. Знать о каких-то очередях, мутексах и.т.п. совершенно необязательно. Это "технология", зарядил - получил (результат);

Ну и зачем пытаться с этим соревноваться? Так, показать свой (высокий) класс?

@Aledveu · 05.08.2025, 20:46

Сообщение от Igor3D

Простое и удобное использование, "кидаем в мешок" задачи, пул ими займется. Потом waitForDone, все посчитано. Знать о каких-то очередях, мутексах и.т.п. совершенно необязательно

Это потому что у вас очень простые задачи. Как только вы будете в многопотоке работать с большими общими структурами данных - там будет куча мьютексов ))

cdcodecpp · 05.08.2025, 21:16 **[ТС]**

Продублирую вопросы, чтобы не потерялись. Нежужели никто не знает ответы?

Сообщение от cdcodecpp

5. Есть ли санитайзер для Windows, ищущий data race?
6. Иногда на Linux Address Sanitizer ловил ошибки, связанные с data race, которые должен ловить Thread Sanitizer. Правильно я понимаю, что нередко Address Sanitizer может поймать ошибки, связанные с многопоточностью (Thread Sanitizer) и что это не связанно с уникальностью тех учебных багов, с которыми я столкнулся?
7. В книге Вильямса есть пример очереди без блокировок, построенной на атомиках и подсчёте ссылок, когда push и pop из 5 строчек разбухают в 50. Часто ли встречаются на практике такие запутанные алгоритмы с подсчётом ссылок или этот код был показан как учебный пример?
8. (Ответили, что всё верно) Допустим, есть очередь, в которой есть задачи, которые надо распределять по потокам. Правильно я понимаю, что если время выполнения каждой такой задачи достаточно велико, то нет необходимости придумывать, как сделать очередь (или другую структуру) свободной от блокировок и от ожиданий? Правильно я понимаю, что необходимость кода, который свободен от блокировок и/или ожиданий возникает только тогда, когда задачи, которые выполняются каждым из потоков, выполняются за достаточно малое время и сопоставимы с временными затратами, которые расходуются на мьютексы и атомики?
10. Правильно я понимаю, что memory_order_relaxed используется только в комбинации с memory_order_acquire / memory_order_release и / или memory_order_seq_cst и служит для оптимизации и ускорения кода? Сам по себе, без других семантик, он никакого смысла не несёт?
11. Правильно я понимаю, что acquire и release не должны обязательно вызываться в коде парами и друг за другом, что как вызов acquire, так и вызов release могут улететь вникуда, не дождавшись "дополняющего" вызова? Что метод push, содержащий release, может вызваться 100 раз, а метод pop, содержащий aquire, только 10. Как и наоборот: pop 100 (например, в конструкторе произошло добавление 1000 элементов без помощи метода push), а push 10. Если для конкретного aquire не обязательно должен быть конкретный release, а для конкретного release не обязательно должен быть конкретный aquire, то они нужны только для того, чтобы код ускорился за счёт более оптимального распределения команд (процессором и компилятором) по сравнению с seq_cst, не перемешав при этом эти самые команды для тех случаев, когда вызовы pop и push прекрылись во времени?
12. Вот пример кода для стэка без блокировок из книги Вилльямса.
Правильно я понимаю, что aquire / release нужны только для того, чтобы позволить процессору и компилятору сдвигать команды с целью оптимизации и ускорения и в тоже время быть уверенным, что всё, что было до release, там и останется, как и всё, что оказалось после aquire не сдвинется выше? Надо только, чтобы в процессе оптимизации, выполняемой компилятором и процессором, не произошло сдвига строчек кода (машинных команд) вниз (для release) или вверх (для aquire).

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
#include <memory>
#include <atomic>
#include <thread>
// clang -std=c++2a -m64 -o lock_free_stack.exe lock_free_stack.cpp
using namespace std;
template<typename T> class lock_free_stack {
private:
    struct node;
    struct counted_node_ptr {
        int external_count;
        node* ptr;
    };
    struct node {
        shared_ptr<T> data;
        atomic<int> internal_count;
        counted_node_ptr next;
        node(T const& data_): data(make_shared<T>(data_)), internal_count(0) {}
    };
atomic<counted_node_ptr> head;
void increase_head_count(counted_node_ptr& old_counter) {
        counted_node_ptr new_counter;
        do {
            new_counter = old_counter;
            ++new_counter.external_count;
        }
        while(!head.compare_exchange_strong(old_counter, new_counter, 
            memory_order_acquire, 
            memory_order_relaxed));
        old_counter.external_count = new_counter.external_count;
    }
public:
    ~lock_free_stack() {
        while(pop());
    }
void push(T const& data) {
        counted_node_ptr new_node;
        new_node.ptr = new node(data);
        new_node.external_count = 1;
        new_node.ptr->next = head.load(memory_order_relaxed);
        while(!head.compare_exchange_weak(new_node.ptr->next, new_node, 
            memory_order_release, 
            memory_order_relaxed));
    }
shared_ptr<T> pop() {
        counted_node_ptr old_head = head.load(memory_order_relaxed);
        for(;;) {
            increase_head_count(old_head);
            node* const ptr = old_head.ptr;
            if(!ptr) {
                return shared_ptr<T>();
            }
            if(head.compare_exchange_strong(old_head, ptr->next, memory_order_relaxed)) {
                shared_ptr<T> res;
                res.swap(ptr->data);
                int const count_increase = old_head.external_count-2;
                if(ptr->internal_count.fetch_add(count_increase, memory_order_release) == -count_increase) {
                    delete ptr;
                }
                return res;
            }
            else if(ptr->internal_count.fetch_add(-1, memory_order_relaxed) == 1) {
                (void)ptr->internal_count.load(memory_order_acquire);
                delete ptr;
            }
        }
    }
};
int main() {
    lock_free_stack<int> s;
    s.push(1);
    s.push(2);
    (void)s.pop();
    return 0;
}

@SmallEvil · 05.08.2025, 21:23

Сообщение от cdcodecpp

Нежужели никто не знает ответы?

16. Запрещено создавать темы с множеством вопросов во всех разделах, кроме разделов платных услуг. Один вопрос - одна тема.

@Igor3D · 05.08.2025, 22:51

Сообщение от Aledveu

Это потому что у вас очень простые задачи.

Не сказал бы.

Сообщение от Aledveu

Как только вы будете в многопотоке работать с большими общими структурами данных - там будет куча мьютексов ))

На это можно посмотреть и иначе: куча мутексов - значит данные спланированы плохо, нужно (хотя бы) стремиться к отсутствию блокировок

Сообщение от cdcodecpp

Нежужели никто не знает ответы?

С "нежужели" хорошо получилось, сочно звучит

Но Вы слишком много хотите. Напр пункт 11 - хороший вопрос. И по смыслу хочется ответить "да, так, верно". Но... где это написано? Найти этому подтверждение в стандарте (или в авторитетной книге) очень непросто (если оно там вообще есть). А ответ типа "ну это я так думаю" не удовлетворит пытливых изучающих

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

- верно ли что с семантикой relaxed поведение то же что и для не-атомиков, во всяком случае для "atomistic" типов, напр int?

- есть ли возможность/семантика синхронизировать только одну/данную переменную с целью макс производительности? То что в каких-то случаях атомики тормозят (пусть не смертельно) замечено давно

И.т.п.

И наконец то о чем Вам сказали все. У Вас есть опыт простого (житейского, бытового) "разпоточивания"? Чем упорнее Вы отмалчиваетесь - тем крепче подозрение что никакого. А если так, то Ваш план изучения многопоточности, мягко говоря, неудачен. Это типа хотите брать производные/интегралы не освоив таблицу умножения. Поэтому да, нежужели

cdcodecpp · 05.08.2025, 23:22 **[ТС]**

Сообщение от Igor3D

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

Я не отмалчиваюсь, опыта почти нет, если не считать решение тех задач, которые хорошо распараллеливаются, а также доделывание многопоточного кода. В этом коде конкретно мне не надо было изменять логичку многопоточности или добавлять новые объекты синхронизации, надо было аккуратно доделать функции, не обрушив приложение. Многопоточные баги тоже приходилось искать, использовал санитайзеры, но на Linux. Надеюсь, ответил на ваш вопрос.
А как ещё изучать многопоточность, если не с прорабатывания книги Вильямса? Наверное, есть какие-то книги с задачками или сайты, если знаете, посоветуйте, пожалуйста.

Добавлено через 4 минуты

Сообщение от Igor3D

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

Как тогда используют эту семантику, если не знают, как она работает? Просто пишут тесты и смотрят, как код показывает себя , а если в 1 случае из миллиона будет ошибка, то это считается допустимой погрешностью? Или не используют её, а используют seq_cst?

Новые блоги и статьи Все статьи Все блоги /
Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .
Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .

@Aledveu 267 / 199 / 30 Регистрация: 26.11.2022 Сообщений: 866
	04.08.2025, 11:42
	cdcodecpp, проблема с санитайзерами при многопотоке в том что они не понимают что за задачу вы решаете. Ну может только в самых простых случаях. Поэтому чтобы не делать одних и тех же ошибок и не полагаться на санитайзер каждый раз надо написать код который решает вашу задачу и потом только повторно его использовать и не менять. Например: есть mpmc очередь. Это базовый кирпичи для любой многопоточной программы, да и вообще это очень удобный примитив. Еë один раз написал, протестил (что тоже не тривиально) и больше не прикасается к ней. Следующий базовый кирпичик это пул потоков. Вот когда вы эти базовые части попереписываете несколько раз когда будете добавлять в них нужный вам функционал , выделите их в отдельную независимую от проекта библиотеку то тогда и появится некоторое понимание. 0