Вопрос про потоки и мьютексы (си)

т.е. это глобальная константа? Или эта переменная не просто число, не атомарна? Если какой-то (основной например) поток ее всё же меняет, я бы от греха подальше защитил ее локом...

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

Upd. На счет изменения переменной в глобальном потоке полностью согласен с оратором выше.

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

Если, допустим, она меняется редко, то лучше тогда вообще семафоры использовать? Они не так садят производительность.

Глобальная int, меняется в основном цикле.

А какие последствия? В момент когда переменная перезаписывается её читает поток, что, кроме получения неверных данных, может произойти?

Неверный вход — неверный выход, не? Если от ложного значения переменной мало что зависит, то всё равно это как минимум моветон оставлять её без защиты в твоём случае.

Глобальная int, меняется в основном цикле.

А какие последствия? В момент когда переменная перезаписывается её читает поток, что, кроме получения неверных данных, может произойти?

Оснавная суть последствий будет в том что если кроме этой перемкнной меняются и какието другие данные — то нить (поток, как ты называешь) которая читает эти данные и переменную прочитать может не в том порядке в котором это было изменено..

И кстати синхронизация фьютексом (мьютексом) конечно эту ситуацию хоть и исправляет — но это как из пушки стрелять по воробьям.

Есть же специально —

memory_order_acquire и memory_order_release

>это как минимум моветон оставлять её без защиты

Несомненно Вы правы.

А подскажите ещё, что делает флаг -D_REENTRANT при компиляции?

Если переменная не атомарная, то лучше защити мьютексом. Чтобы во время записи никто мусор не прочитал.

то лучше защити мьютексом

А мьютекс надо ставить только там где переменная перезаписывается или где читается тоже ставить?

сделай ее volatile еще :)

пишется -> lock, пока пишется, нельзя читать

сделай ее volatile еще :)

Смешно)

...

Вот бы кто про это подсказал...

А подскажите ещё, что делает флаг -D_REENTRANT при компиляции?

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

Мне за тебя погуглить? Гугль говорит, что тогда компилятор использует потокобезопасные функции сишных либ. Они есть в двух версиях часто, безопасные и медленные и быстрые и небезопасные.

Всё что угодно может произойти.

Вон из профессии!

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

Это я понимаю, не понятно другое, если использовать этот флаг, то можно не пользоваться мьютексами? Или эти «потокобезопасные функции сишных либ» добавляют безопасности?

Если переменная не меняется никаким другим потоком, защищать не надо, если меняется защищать надо всегда, иначе UB (программа ill-formed).

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

Вот на русском даже, на 1 странице гугла https://ru.wikipedia.org/wiki/Реентерабельность

Переменная меняется только одним потоком...

int count = 0;

void * thread_count_func() 
 { 
   for(;;) 
    { 
      sleep(1);
      count++;
    } 
 } 

Остальные потоки выполняют эту функцию...

void * other_thread_func() 
 { 
   int bla = 0;
   bla = count;
 } 

Дык надо защищать или нет?

Это вообще про другое

Собственно про этот флаг говорится на opennet.ru https://www.opennet.ru/base/dev/linux_threads.txt.html

Атомики придумали не для этого?

Вроде там написано совсем про другое.

В glibc int считается атомарным :-) Пруф :-)

Конечно надо. Вот определение гонки:

A data race occurs when: two or more threads in a single process access the same memory location concurrently, and. at least one of the accesses is for writing, and. the threads are not using any exclusive locks to control their accesses to that memory.

У тебя все три пункта: есть потоки + есть общая область в памяти + один из потоков туда пишет. Значит если не защитишь, то будет гонка, а это UB, и его в программе быть не должно.

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

Ты все атомарные переменные блокировками прикрываешь? Типа так надежнее?

Captcha: GIBBS PEATON

Твой пруф не про потоки, а только про signal handlers. Вот в C11 добавили настоящие Atomic, и они не int.

Твой пруф не про потоки, а только про signal handlers.

Открой глазки шире и посмотри внимательней: «In practice, you can assume that int is atomic. You can also assume that pointer types are atomic; that is very convenient.» :-)

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

Ты все атомарные переменные блокировками прикрываешь? Типа так надежнее?

атомарные переменные используют спец инструкции процессора для чтения и записи (LDREX, STREX) которые выролняют синхронизацию на уровне железа. Для них блокировки не нужны.

Первая ссылка в гугле, самая первая. Ты бы хоть погуглил http://stackoverflow.com/questions/9606725/linux-why-is-sig-atomic-t-typedefe...

Первая ссылка в гугле, самая первая. Ты бы хоть погуглил

Ты теоретик? :-) Зачем что-то гуглить, если есть официальная документация, в которой сказано, что на практике int - атомарный тип? :-)

Может форков() наклепать, а данные через файл перекидавать?

В стандарте этого нет и есть реальное железо, для которого это будет не так.

В стандарте этого нет и есть реальное железо, для которого это будет не так.

Не возражаю :-) Но в доке от GNU сказано: «Both of these assumptions are true on all of the machines that the GNU C Library supports and on all POSIX systems we know of.» :-)

А чуть выше написано что это все гарантируется только в контексте signal handler. Может у тебя плохое зрение и ты не видишь приставку sig в слове sig_atomic_t ?

А чуть выше написано что это все гарантируется только в контексте signal handler. Может у тебя плохое зрение и ты не видишь приставку sig в слове sig_atomic_t ?

Удивительные люди :-) Лол :-) Нет, у меня зрение в норме, в отличии от :-) Ведь у меня не возникает фантазий, контекстов каких-то или сомнений, когда читаю, написанное черным по белому: «In practice, you can assume that int is atomic.» :-) Где ты в этом предложении увидел sig handler, приставку sig, слово sig_atomic_t - мне не ведомо :-)

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

написанное черным по белому

На заборе тоже написано...
Глава 24 из которой ты выдираешь слова без контекста называется
24 Signal Handling
24.4 Defining Signal Handlers
24.4.7 Atomic Data Access and Signal Handling
24.4.7.2 Atomic Types
Как можно тут не заметить слово signal? Есть только два варианта или у тебя избирательная слепота, или ты ничего не читал из этой доки кроме одного предложения.

В комментариях к вышеупомянутому посту высказана интересная точка зрения. Да, это там где num--. Вот это, если говорить конкретно. Если я верно понимаю то, что написано по ссылке, то инт атомик только в отношении сигналов.

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

Глава 24 из которой ты выдираешь слова без контекста называется

Глава 24.4.7.2 называется «Atomic Types» :-) Контекстом является «Atomic Types» (в переводе на русский язык - «атомарные типы данных») :-) Там ведётся речь о типе sig_atomic_t :-) В конце там говорится, что «In practice, you can assume that int is atomic.» (в переводе на русский язык - «На практике можете считать int атомарным типом данных» :-)

Как можно тут не заметить слово signal? Есть только два варианта или у тебя избирательная слепота, или ты ничего не читал из этой доки кроме одного предложения.

Других вариантов, кроме как то, что int и указатели - атомарные типы на всех машинах, где работает GNU C Library и на всех системах POSIX, с которыми знакомы разработчики GNU C Library, о чём они и говорят: «Both of these assumptions are true on all of the machines that the GNU C Library supports and on all POSIX systems we know of.» :-)

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

Если я верно понимаю то, что написано по ссылке, то инт атомик только в отношении сигналов.

int он и в Африке int :-)

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

Так а ты не выглядишь вообще никак, и вообще пруфов не приводишь, кроме как рассуждения частных лиц на stackoverflow :-) Но кто бы как не рассуждал, есть официальная документация от GNU :-) Не веришь ей - вводи мьютексы вокруг int :-) Лол :-)

Что такое атомарный тип данных? Атомарными бываю операции. i++ не атомарная операция.

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

Что такое атомарный тип данных? Атомарными бываю операции. i++ не атомарная операция.

Просто же: атомарный тип данных - это тип данных, любая операция над которым атомарна :-)