Неоднозначная ситуация с функцией преобразования в классе

Eagle, ещё один решил высказаться, не разбираясь?

__atomic_fetch_add это встроенная функция [1], которая вызывается из libatomic при следующих условиях:

Как можно видеть из ассемблерного листинга, никаких вызовов функций __atomic_fetch_add или pthread_mutex_* там нет, а применение встроенной функции просто превратилось в инструкции с lock-префиксом.

[1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

 

Значит, ещё раз. Есть спинлок - сам алгоритм взятия блокировки, а есть спинлок - объект синхронизации. Вы пытаетесь меня поймать на формулировке терминов, пытаясь увильнуть от очевидного факта - при работе с shared_ptr так или иначе осуществляется захват блокировки, основанной на атомиках. Именно потому, что нет никаикх вызовов pthread_* функций, а также системных вызовов futex, yield и прочих, эти процедуры блокировки нельзя рассматривать иначе как спин-блокировки.

 

Я не перехожу на личности ни в коем случае - если вы конечно в состоянии воспринимать мою оценку взвешенно/абстрактно. Мой опыт научил меня ценить людей по их поступкам а не по admin permissions. И мне глубоко #### на то что кто-то меня тут забанит. А наблюдаю я тут довольно привычную картину - нежелание выяснить истину. Вам проще забанить, ну так скатертью дорога...

 

Ну что ж поделать - не в коня корм. Я также удалил ваш форум из своих закладок. Общайтесь с topic starter'ом - в принципе это ваш выбор

 

Eagle,

Скатертью дорога. Незачем чушь писать. Не охота читать весь топик, но на сколько я понял вам на столько сишная парадигма залипла в мозги, что вы уже видите реальность в сишном формате. Корреляция в терминах, спинлок vs атомарные операции ?

Так вам выше конкретно сказали:

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

 

SadKo, сначала ты писал про спин-блокировки, потом дал заднюю и написал, что ты некорректно употребил слово "блокировки", потом опять изменил своё мнение сказал, что спин-блокировки есть и это — ячейки памяти (!!!). В общем, ты вконец запутался в показаниях. Это уже не смешно, а просто уныло.

Ты (не я!) выше дал ссылку, где спинлоком называется попытка захвата блокировки в цикле. Теперь ты пишешь, что циклов здесь нет. Но спинлоки есть.
Ты сам читаешь то, на что даёшь ссылки? Или ты всё тут пишешь не приходя в сознание?

 

CurryHowardIsomorphism, вы всё ещё пытаетесь меня на терминологии поймать? Мне уже как-то скучно стало. Ещё раз говорю: есть спин-блокировка как объект, есть спин-блокировка как процесс. Изначально я говорил про "дёргаются спин-блокировки" именно как про объект синхронизации. А то, что в отдельных методах, работающих с одними и теми же ячейками памяти, оно реализовано как атомарные операции без цикла или с циклом, уже имеет второстепенное значение. Вы стали жонглировать, говоря, что там спинов нет, я вам привёл конкретный код, где поля класса реально использовались как спины согласно определению из википедии. Вас это снова не удовлетворило, ну ок, я, может и засомневался в своих выводах, и сделал поправку, что это атомики. Однако для меня это сути вещей не меняет: спины не могут быть реализованы без использования атомарных операций.Всё, что не делает системного вызова на переключение контекста, ожидание или прочее, есть спин-блокировка.
В общем, мне это разбирательство "спин-не спин" надоело. Вы ушли от темы, а именно - ущербности кодогенерации при подобном подходе. Посмотрите, обычные shared_ptr, а компилятор так засрал код.

 

Код (C++):

1. Num Num::operator+(int num) {
2. return Num(this->n+num);
3. }