(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_contested ()

Обратите внимание, что компилятор C полностью предварительно вычисляет все константные выражения. Фактически, компилятор может даже оптимизировать встроенный код на основе условных выражений, которые используют переданные аргументы процедур, когда процедурам передаются константы в этих аргументах. Вот почему встроенный в sys / lock.h файл lockmgr () имеет оператор case .... потому что весь оператор case будет оптимизирован и превращен в прямой вызов соответствующей функции.

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

Матф

Код находится в _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, оно оставлено как есть, чтобы уточнить цель сравнения (т. Е. Сравнить увеличенное предыдущее значение с тестовым значением).

Или да. Ответ, кажется, для ясности и последовательности кода.

Я думаю, что цель, вероятно, состоит в том, чтобы игнорировать младший значащий бит:

• Если 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