LINUX.ORG.RU

А как бы в gcc получить 128-bit atomic — always lock free?

 ,


0

2

Гуглится всякое шушушу (в т.ч. давнишнее, в т.ч. в багтрекере gcc, дескать можно заюзать SSE, в т.ч. с коммитами), но по факту хрен:

__atomic_always_lock_free(16, nullptr) == false
std::atomic<__int128_t>::is_always_lock_free == false

Это и для march=x86-64, и march=native (AMD Ryzen 9 7845HX).

★★★★★

DeepSeek у телефона

#include <stdbool.h>
#include <stdio.h>

int main() {
    uint128_t atomic_var = 0;

    // Check if 128-bit atomic operations are lock-free
    bool is_lock_free = __atomic_is_lock_free(sizeof(uint128_t), NULL);
    printf("128-bit atomic is lock-free: %s\n", is_lock_free ? "true" : "false");

    // Perform atomic operations
    uint128_t value = 123456789012345678901234567890ULL;
    __atomic_store_n(&atomic_var, value, __ATOMIC_RELAXED);

    uint128_t loaded_value = __atomic_load_n(&atomic_var, __ATOMIC_RELAXED);
    printf("Loaded value: %llu\n", (unsigned long long)loaded_value);

    return 0;
}

gcc -o atomic_test atomic_test.c -latomic

Platform considerations

  • x86-64 with CMPXCHG16B: On x86-64 architectures that support the CMPXCHG16B instruction, 128-bit atomic operations can be lock-free.
  • Other architectures: On architectures without native 128-bit atomic support, GCC may use locks internally, making the operations non-lock-free.
zg
()
Ответ на: комментарий от dimgel

Нерабочий код и ИИшный код - ортогональные вещи. @zg запостил первое, за это ему лучи поноса и клеймо профнепригодности. И несмотря на то что ИИшный код часто нерабочий, если он получился рабочим или был доведён до такого состояния, как он был получен - ничьё собачье дело. Что касается генту, я принципиально последние месяцы генерю ебилды чатгптой, причёсываю и сабмичу. Может решу когда их наберётся критическая масса и от них будут зависеть другие пакеты, сделать каминг аут и предложить сообществу последовать своим правилам и всё это удалить.

anonymous
()
Ответ на: комментарий от dimgel

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

в чем проблема ИИ кода?, если конечно указывать что это ИИ. вопрос в том - даете ли вы какие-то гарантии его работоспособности, а если нет, то почему.

alysnix ★★★
()
Ответ на: комментарий от dimgel

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

#include <stdatomic.h>
#include <stdbool.h>
#include <stdio.h>

int main() {
    __uint128_t atomic_var = 0;

    // Check if 128-bit atomic operations are lock-free
    bool is_lock_free = atomic_is_lock_free(&atomic_var);
    printf("128-bit atomic is lock-free: %s\n", is_lock_free ? "true" : "false");

    // Perform atomic operations
    __uint128_t value = 123456789012345678901234567890ULL;
    __atomic_store_n(&atomic_var, value, __ATOMIC_RELAXED);

    __uint128_t loaded_value = __atomic_load_n(&atomic_var, __ATOMIC_RELAXED);
    printf("Loaded value: %llu\n", (unsigned long long)loaded_value);

    return 0;
}
zg
()
Ответ на: комментарий от zg

Ага, компиляется. Но во-первых коряво, а во-вторых, показывает то же самое lock-free = false – т.е. на мой вопрос не отвечает:

$ gcc -o atomic_test atomic_test.c -latomic
atomic_test.c: In function ‘main’:
atomic_test.c:13:25: warning: integer constant is too large for its type
   13 |     __uint128_t value = 123456789012345678901234567890ULL;
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ ./atomic_test 
128-bit atomic is lock-free: false
Loaded value: 14083847773837265618

Поздравляю вас, гражданин, соврамши дважды обосрамшись.

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

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 1)

Везде пишут, что в крайних x86_64 есть 128 битный CAS. Так что хватит придуриваться типа не можешь.

А вообще arm и risc-v с их LL/SC это база. Переходи на них.

ox55ff ★★★★★
()
Ответ на: комментарий от dimgel

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

zg
()
Ответ на: комментарий от zg

Надо же, заставил других людей впустую потратить время – и ещё претензии выкатывает.

А, во, вспомнил: в игнор. :)

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от vbr

Да, это тоже уже нашёл, в каком-то из ответов на SO была ссылка на сравнение поведений (gcc vs clang, __sync vs __atomic): https://godbolt.org/z/4bbfm6

Но эти __sync – вроде как уже deprecated в пользу __atomic, которые почему-то всегда завёрнуты в вызов libatomic (см. цитату и ссылку в моём 2м каменте). Что им мешает заинлайнить инструкцию – хз. :/

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 2)
Ответ на: комментарий от dimgel

Ну собственно я на это вышел через изучение https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html где написано

-mcx16

This option enables GCC to generate CMPXCHG16B instructions in 64-bit code to implement compare-and-exchange operations on 16-byte aligned 128-bit objects. This is useful for atomic updates of data structures exceeding one machine word in size. The compiler uses this instruction to implement Legacy __sync Built-in Functions for Atomic Memory Access. However, for Built-in Functions for Memory Model Aware Atomic Operations operating on 128-bit integers, a library call is always used.

Так что вот так.

Также замечу, что там написано legacy, а не deprecated. Есть основания полагать, что это разные вещи в плане вероятности выкидывания в обозримом будущем.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

Также замечу, что там написано legacy, а не deprecated. Есть основания полагать, что это разные вещи в плане вероятности выкидывания в обозримом будущем.

Хм, а вообще это идея, надо подумать. (Я видел про deprecated не в самой доке, а где-то на SO, но видимо это было враньё.) Там ещё смущало описание (не помню, старых или новых): не упоминалось, что при неудаче compare_exchange загружает actual в expected. Хотя это и проверяется тривиально, и хрен с ним если на загружает.

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

Надо же, заставил других людей впустую потратить время – и ещё претензии выкатывает.

Надо же, какая самокритика!

А, во, вспомнил: в игнор. :)

Молодец, сиди тихо теперь.

zg
()