(x | y) - y чому це не може бути просто x або навіть `x | 0`

Я читав код ядра, і в одному місці я побачив вираз всередині ifоператора, як

if (value == (SPINLOCK_SHARED | 1) - 1) {
         ............
}

де SPINLOCK_SHARED = 0x80000000є заздалегідь визначена константа.

Цікаво, навіщо нам це потрібно (SPINLOCK_SHARED | 1) - 1- для перетворення типу? результат вираження буде 80000000-- такий же, як 0x80000000, чи не так? все-таки, чому питання ORing 1 і віднімання 1 мають значення?

У мене таке відчуття, ніби я сумую, щоб щось дістати ..

Це було зроблено саме так для наочності, ось і все. Це тому, що atomic_fetchadd_int () (наприклад, sys / spinlock2.h) повертає значення PRIOR на додавання / віднімання, і це значення передається _spin_lock_conested ()

Зауважте, що компілятор C повністю попередньо обчислює всі постійні вирази. Насправді компілятор може навіть оптимізувати вбудований код на основі умовних умов, які використовують аргументи переданих процедур, коли процедури передаються константами в цих аргументах. Ось чому lockmgr (), вбудований в sys / lock.h, має випадок випадку .... тому що весь випадок справи буде оптимізований та перейде в прямий виклик відповідної функції.

Крім того, у всіх цих замикаючих функціях накладні атомні оси карликовують усі інші обчислення на два-три порядки.

-Матт

Знайдено код _spin_lock_contested, який викликається, _spin_lock_quickколи хтось інший намагається отримати замок:

count = atomic_fetchadd_int(&spin->counta, 1);
if (__predict_false(count != 0)) {
    _spin_lock_contested(spin, ident, count);
}

Якщо немає змагань, то count(попереднє значення) має бути 0, але це не так. Це countзначення передається як параметр, _spin_lock_contestedяк valueпараметр. Потім valueце перевіряється за ifдопомогою ОП:

/*
 * WARNING! Caller has already incremented the lock.  We must
 *      increment the count value (from the inline's fetch-add)
 *      to match.
 *
 * Handle the degenerate case where the spinlock is flagged SHARED
 * with only our reference.  We can convert it to EXCLUSIVE.
 */
if (value == (SPINLOCK_SHARED | 1) - 1) {
    if (atomic_cmpset_int(&spin->counta, SPINLOCK_SHARED | 1, 1))
        return;
}

Маючи на увазі, що valueпопереднє значення spin->counta, а останнє вже збільшено на 1, ми очікуємо, що воно spin->countaбуде рівним value + 1(якщо щось не змінилося тим часом).

Отже, перевірка того, що spin->counta == SPINLOCK_SHARED | 1(передумова atomic_cmpset_int) відповідає перевірці, якщо value + 1 == SPINLOCK_SHARED | 1, що можна переписати як value == (SPINLOCK_SHARED | 1) - 1(знову ж таки, якщо нічого за цей час не змінилося).

Хоча це value == (SPINLOCK_SHARED | 1) - 1може бути переписано як value == SPINLOCK_SHARED, залишається таким, як є, для уточнення наміру порівняння (тобто порівняння нарощеного попереднього значення з тестовим значенням).

Або iow. начебто відповідь: для ясності та послідовності коду.

Я думаю, що ціль - це, мабуть, ігнорувати найнижчий значущий біт:

• Якщо SPINLOCK_SHARED, виражений у двійковій формі, є xxx0 -> результат - xxx0
• Якщо SPINLOCK_SHARED = xxx1 -> результат також xxx0

було б, мабуть, зрозуміліше використовувати експрес-маску?

Ефект від

(SPINLOCK_SHARED | 1) - 1

полягає у тому, щоб забезпечити очищення бітового результату низького порядку перед порівнянням з value. Я погоджуюся, що це здається досить безглуздим, але, мабуть, біт низького порядку має певне використання або значення, що не видно в цьому коді, і я думаю, що ми повинні припустити, що у розробників були вагомі причини для цього. Цікавим було б питання - чи використовується той самий шаблон ( | 1) -1) у всій кодовій базі, яку ви дивитесь?

Це заплутаний спосіб написання трохи маски. Читається версія: value == (SPINLOCK_SHARED & ~1u).

Найбільш подібне робиться для обробки кількох додаткових справ. Наприклад, у цьому випадку ми говоримо, що SPINLOCK_SHAREDне може бути 1:

int SPINLOCK_SHARED = 0x01

int res = (SPINLOCK_SHARED | 1) - 1 // 0