Программирование[11]

Kant написал 1 минуту назад:

ну ахуеть ты что вспомнил

 

Вроде есть десятка винда 32битная.

Kant написал 3 минуты назад:

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

Ну прикинь а вот жава искаропки на 32битах позволяет с 1995 работать с 64битными примитивами.

(пусть и жертвой атомарности)

Just.Doit написал 9 часов назад:

 

Vova написал 17 часов назад:

на обычных компах

оу май

в какой момент мы начали ограничивать платформы?

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

Да тот код никто не воспроизвел ни на одной платформе.

Я просто для уверенности говорю что на почти всех платформах он не воспроизведется. На самом деле скорей всего он нигде и никогда не воспроизведется даже на PowerPC.

Index написал 15 минут назад:

Kant написал 19 минут назад:

ну ахуеть ты что вспомнил

 

Вроде есть десятка винда 32битная.

Kant написал 19 минут назад:

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

 

Ну прикинь а вот жава искаропки на 32битах позволяет с 1995 работать с 64битными примитивами.

(пусть и жертвой атомарности)

а ты найди для начала 32 битный процессор сейчас дома у кого-нибудь

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

Kant написал 4 минуты назад:

а ты найди для начала 32 битный процессор сейчас дома у кого-нибудь

 

Ничто не мешает поставить 32битную ОС на 64битный процессор.

Windows 10, the last Windows operating system to support 32-bit operation, will reach End of Life in October 2025.

scarppy написал 38 минут назад:

вы хоть знаете чем спан от дива отличается

умники блять

Дива (мифология)

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

Grohuf написал 18 часов назад:

Kant написал 21 час назад:

Grohuf написал 11.06.2024 в 04:49:

@Vova

Смотри что нашел!

https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedexchange

Совсем ебанулись, да? Они че, не знают, что 32 битные значения на 32 битных компьютерах записываются АТОМАРНО! Они для этого функцию сделали, хотя уже 386 были 32 битным. Ахахаха, всегда знал, что Билл Гейтс - шизик.

эта функция делает два действия, читает и пишет

два действия отдельно не являются атомарными по определению, поэтому и существует специальная инструкция

сами запись и чтение всегда атомарны, тк меньше них сука уже ничего просто нет

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

Не помогай вове!

Я тут причем? @Kant тебе ответил долбаебу что это функция нужна уже потому что она делает ДВА ДЕЙСТВИЯ даун

Даже если ты всунешь по барьеру в кажду строчку кода ДВА ДЕЙСТВИЯ не стан вдруг атомарными:

int exchange(std::atomic<int>& var, int new_value)
{
    std::atomic_thread_fence(std::memory_order_seq_cst);
    int old_value = var.load();
    std::atomic_thread_fence(std::memory_order_seq_cst);
    var.store(new_value);
    std::atomic_thread_fence(std::memory_order_seq_cst);
    return old_value;
}

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

Vova написал 9 минут назад:

Даже если ты всунешь по барьеру в кажду строчку кода ДВА ДЕЙСТВИЯ не стан вдруг атомарными:

никто даже не заикнулся про атомарность

речь про последовательность событий и их возможные порядки с точки зрения наблюдателя (того кто их читает)

мемори ордер это про ордер, а не про атомарность

Index написал 2 часа назад:

Kant написал 2 часа назад:

а ты найди для начала 32 битный процессор сейчас дома у кого-нибудь

 

Ничто не мешает поставить 32битную ОС на 64битный процессор.

Windows 10, the last Windows operating system to support 32-bit operation, will reach End of Life in October 2025.

 

ничто не мешает мне и дос на свой комп поставить, на обсуждении это никак не скажется

Just.Doit написал 1 час назад:

Vova написал 1 час назад:

Даже если ты всунешь по барьеру в кажду строчку кода ДВА ДЕЙСТВИЯ не стан вдруг атомарными:

никто даже не заикнулся про атомарность

речь про последовательность событий и их возможные порядки с точки зрения наблюдателя (того кто их читает)

мемори ордер это про ордер, а не про атомарность

 

Я это и говорю - речь была про последовательность событий.

@Grohuf дал ссылку на read-modify-write функцию и спрашивает зачем она нужна если запись int атомарная (я не утверждал что запись int атомарная ВСЕГДА это @Grohuf сам придумал снова).

НУ КАК БЫ ДАЖЕ С ЛИНЕЙНОЙ ПОСЛЕДОВАТЕЛЬНОСТЬЮ СОБЫТИЙ И АТОМАРНОЙ ЗАПИСЬЮ read-modify-write НЕ СТАНОВЯТСЯ АТОМАРНЫМИ

Пруф того что по логики долбаеба из атомарности записи int должна следовать атомарность read-modify-write:

Grohuf написал 11.06.2024 в 04:49:

Смотри что нашел!

https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedexchange

Совсем ебанулись, да? Они че, не знают, что 32 битные значения на 32 битных компьютерах записываются АТОМАРНО! Они для этого функцию сделали, хотя уже 386 были 32 битным. Ахахаха, всегда знал, что Билл Гейтс - шизик.

@Grohuf в следующий раз тащи сразу функцию на 100 строчек обложенную мьютексами и спрашивай зачем ее сделали

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

Vova написал 59 минут назад:

Я это и говорю - речь была про последовательность событий.

 

@Grohuf дал ссылку на read-modify-write функцию и спрашивает зачем она нужна если запись int атомарная (я не утверждал что запись int атомарная ВСЕГДА это @Grohuf сам придумал снова).

 

НУ КАК БЫ ДАЖЕ С ЛИНЕЙНОЙ ПОСЛЕДОВАТЕЛЬНОСТЬЮ СОБЫТИЙ И АТОМАРНОЙ ЗАПИСЬЮ read-modify-write НЕ СТАНОВЯТСЯ АТОМАРНЫМИ

 

Пруф того что по логики долбаеба из атомарности записи int должна следовать атомарность read-modify-write:

ты говорил про атомарность инта

объясни плс как из "все операции с инт атомарны" -> "так что такого случая произойти не может"

я до сих пор не понимаю как атомарность инта связана с выстраиванием послежовательностей чтения-записи по 2+ переменным

Более того

если баг не воспроизводится, это не значит что его нет

про что блять и речь

бы мне объясни какая часть спеки гарантирует корректное поведение 

и более того, объясни почему это воспроизводится на 2х потоках? ведь код корректный и бага быть не должно

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

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

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

и опять же, я не понимаю причем здесь инт и его атомарность вообще блять

Более того.

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

более того в спеке по плюсам дословно написано

> The synchronization is established only between the threads releasing and acquiring the same atomic variable. Other threads can see different order of memory accesses than either or both of the synchronized threads.

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

либо я не знаю о какой-то еще фичи плюсов которая упорядочет чтения-записи этих 2х переменных (cat и panda) и гарантирует что они будут прочитаны в одинаковом порядке 

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

но возможно я что-то не знаю про атомарность интов в плюсах что начинает гарантировать порядок операций в req/aq для 2+ переменных

Just.Doit написал 18 минут назад:

ты говорил про атомарность инта

объясни плс как из "все операции с инт атомарны" -> "так что такого случая произойти не может"

Если бы операции чтения / присвания инта могли быть выполнены на половину у нас были бы проблемы.

Пример когда такое может произойти в с++

struct Big {int64_t a,b,c,d,e,f,g,h,i,... , z;};
Big A, B;
...
A = B;

Последнее присваивание может исполниться на половину

Just.Doit написал 30 минут назад:

я до сих пор не понимаю как атомарность инта связана с выстраиванием послежовательностей чтения-записи по 2+ переменным

Никак

Нужно смотреть на конкретный этот код презентации и что он делает

Если один поток уже увидел изменения в переменной то и последующие чтения из других потоков это изменение тоже увидят - вот и все

Just.Doit написал 34 минуты назад:

бы мне объясни какая часть спеки гарантирует корректное поведение 

Можно посмотреть как выглядит запись с memory_order_seq_cst:

        mov     eax, 12345678
        xchg    eax, DWORD PTR z[rip]

И как выглядит запись с любой другой memory_order:

        mov     DWORD PTR z[rip], 12345678

И как выглядит чтение вообще с любой memory_order:

        mov     eax, DWORD PTR z[rip]

То есть для чтение вообще не добавляются специальных инструкций а для запили с memory_order_seq_cst добавляют инструкцию "слить кэш в общую память"

Vova написал 15 минут назад:

Если бы операции чтения / присвания инта могли быть выполнены на половину у нас были бы проблемы.

да

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

Just.Doit написал Только что:

Vova написал 17 минут назад:

Если бы операции чтения / присвания инта могли быть выполнены на половину у нас были бы проблемы.

да

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

Ответил выше

Vova написал 17 минут назад:

Если один поток уже увидел изменения в переменной то и последующие чтения из других потоков это изменение тоже увидят - вот и все

что это гарантирует?

там нету "последующих" чтений, там конкрурентные чтения, порядок между ними не определен ничем кроме rel/aq семантики

Vova написал 18 минут назад:

То есть для чтение вообще не добавляются специальных инструкций

на одном конкретном компиляторе и на одной конкретной архитектуре

кто гарантирует что этого не произойдет в других условиях?

Vova написал 21 минуту назад:

То есть для чтение вообще не добавляются специальных инструкций а для запили с memory_order_seq_cst добавляют инструкцию "слить кэш в общую память"

попробуй обхяснить тогда зачем их столько?

почему не оставить в с++ только 2 модификатора на запись и вообще убрать все модификаторы на чтение если "И как выглядит запись с любой другой memory_order:" "И как выглядит чтение вообще с любой memory_order:" ?

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

Just.Doit написал 47 минут назад:

и более того, объясни почему это воспроизводится на 2х потоках? ведь код корректный и бага быть не должно

Разные есть варианты почему может быть так:

1) На этапе компилятора убирается полностью чтение переменной которая в том же потоке выставлена true и полностью убирается вообще вся проверка кондишена

2) Запись просходит по схеме lazy write то есть фактический write происходит как самая последняя операция

3) Может быть чтение переменной которая в том же потоке выставлена true все же происходит но читается из локального кэша а не глобальной памяти

Vova написал 1 минуту назад:

Разные есть варианты почему может быть так:

тоесть код не корректный хотя ты говорил что "автор дурак и код будет работать корректно"

Just.Doit написал 8 минут назад:

Vova написал 10 минут назад:

Разные есть варианты почему может быть так:

тоесть код не корректный хотя ты говорил что "автор дурак и код будет работать корректно"

Я что-то утверждал только про код с 4 тредами

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

Just.Doit написал 1 час назад:

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

Перестановки кода компилятором запрещены даже с acquire release семантикой как минимум в с++ это так

Более того там нечего переставлять как бы

Just.Doit написал 1 час назад:

тебе просто повезло в конкретном случае

Мне повезло с вероятностью 100% и уверен повезет снова на любом компиляторе и архитектуре

Пока что эту хуйню с 4 тредами никто нигде не воспроизвел мне продолжает везти

Vova написал 7 минут назад:

Я что-то утверждал только про код с 4 тредами

но код с 4мя тредами не корректный

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

Vova написал 7 минут назад:

Перестановки кода компилятором запрещены даже с acquire release семантикой как минимум в с++ это так

где это прописано?

я не вижу в мемори ордер этого

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

более того есть перестановки на уровне процессора

Vova написал 7 минут назад:

Более того там нечего переставлять как бы

там 2 чтения

ты можешь в рефери прочитать по 0 в кота и в панду когда никто не стартовал, и протом прочитать по 1 когда оба финишировали. и будет баг

ничто не гарантирует отстутсвия данного поведения

Just.Doit написал 2 минуты назад:

 

Vova написал 6 минут назад:

Перестановки кода компилятором запрещены даже с acquire release семантикой как минимум в с++ это так

где это прописано?

я не вижу в мемори ордер этого

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

https://en.cppreference.com/w/cpp/atomic/memory_order

memory_order_acquire A load operation with this memory order performs the acquire operation on the affected memory location: no reads or writes in the current thread can be reordered before this load. All writes in other threads that release the same atomic variable are visible in the current thread (see Release-Acquire ordering below).

memory_order_release A store operation with this memory order performs the release operation: no reads or writes in the current thread can be reordered after this store. All writes in the current thread are visible in other threads that acquire the same atomic variable (see Release-Acquire ordering below) and writes that carry a dependency into the atomic variable become visible in other threads that consume the same atomic (see Release-Consume ordering below).

Just.Doit написал 3 минуты назад:

просто пока не нашлось архитектуры/компилятора который бы так работал

Когда найдется сообщите

Претензия что я слелал вывод в контексте конкретных архитектур процессоров звучит сомнительно учитывая что КОНКРЕТНЫЕ АРХИТЕКТУРЫ упомянуты в моем изначальном посте