（x | y）-yなぜ単純にxまたは `x | 0`

私はカーネルコードを読んでいて、ある場所で次のifようなステートメント内の式を見ました

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

ここで、SPINLOCK_SHARED = 0x80000000事前定義された定数です。

なぜ(SPINLOCK_SHARED | 1) - 1型変換が必要なのでしょうか。式の結果は80000000になります-0x80000000と同じですよね？それでも、なぜORing 1とSubtracting 1が重要なのですか？

何かを手に入れられないような気がします。

分かりやすくするためにそのように行われただけです。これは、atomic_fetchadd_int（）（例：sys / spinlock2.h）が値PRIORを加算/減算に返し、その値が_spin_lock_contested（）に渡されるためです。

Cコンパイラはすべての定数式を完全に事前計算することに注意してください。実際、コンパイラーは、渡されたプロシージャー引数に定数が渡されるときに、渡されたプロシージャー引数を使用する条件に基づいて、インラインコードを最適化することもできます。sys / lock.hのインラインのlockmgr（）にcaseステートメントがあるのはこのためです...そのcaseステートメント全体が最適化され、適切な関数への直接呼び出しに展開されるためです。

また、これらすべてのロック関数では、アトミックopsのオーバーヘッドにより、他のすべての計算が2桁または3桁小さくなります。

-マット

コードはにあり、他の誰かがロックを取得しよう_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次に、これはifOPから確認されます。

/*
 * 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（再度、当面何も変更されていない場合）と書き換えられるifのチェックに対応します。

ながら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_SHARED1にはできません。

int SPINLOCK_SHARED = 0x01

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