(x | y) - y pourquoi ne pas être simplement x ou même `x | 0` ?

Question

Je lisais le code d'un noyau, et à un endroit, j'ai vu une expression à l'intérieur de if comme

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

où SPINLOCK_SHARED = 0x80000000 est une constante prédéfinie.

Je me demande pourquoi nous avons besoin (SPINLOCK_SHARED | 1) - 1 - Le résultat de l'expression serait 80000000 - la même chose que 0x80000000, n'est-ce pas ? Mais pourquoi ORing 1 et Subtracting 1 ont-ils de l'importance ?

J'ai l'impression qu'il me manque quelque chose

Answer 1

Le code se trouve dans _spin_lock_contested qui est appelé à partir de _spin_lock_quick lorsque quelqu'un d'autre tente d'obtenir la serrure :

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

S'il n'y a pas de concours, alors count (la valeur précédente) devrait être 0 mais ce n'est pas le cas. Ce n'est pas le cas. count est transmise en tant que paramètre à _spin_lock_contested en tant que value paramètre. Ce paramètre value est ensuite vérifié avec le if de l'OP :

/*
 * 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;
}

En gardant à l'esprit que value est la valeur précédente de spin->counta et que ce dernier a déjà été incrémenté de 1, on s'attend à ce que spin->counta à égalité value + 1 (à moins que quelque chose n'ait changé entre-temps).

Il s'agit donc de vérifier si spin->counta == SPINLOCK_SHARED | 1 (la condition préalable de la atomic_cmpset_int ) correspond à vérifier si value + 1 == SPINLOCK_SHARED | 1 qui peut être réécrite comme suit value == (SPINLOCK_SHARED | 1) - 1 (encore une fois, si rien n'a changé entre-temps).

Tandis que value == (SPINLOCK_SHARED | 1) - 1 pourrait être réécrite comme suit value == SPINLOCK_SHARED Il est donc laissé tel quel, afin de clarifier l'intention de la comparaison (c'est-à-dire comparer la valeur précédente incrémentée avec la valeur test).

La réponse semble être : pour la clarté et la cohérence du code.

Answer 2

Je pense que l'objectif est probablement d'ignorer le bit de poids faible :

• Si SPINLOCK_SHARED exprimé en binaire est xxx0 -> le résultat est xxx0
• Si SPINLOCK_SHARED = xxx1 -> le résultat est aussi xxx0

Il aurait peut-être été plus clair d'utiliser une expression de masque de bits ?

Answer 3

L'effet de la

(SPINLOCK_SHARED | 1) - 1

est de s'assurer que le bit de poids faible du résultat est effacé avant de procéder à la comparaison avec value . Je suis d'accord que cela semble plutôt inutile, mais apparemment le bit de poids faible a une utilisation ou une signification particulière qui n'est pas apparente dans ce code, et je pense que nous devons supposer que les développeurs avaient une bonne raison de le faire. Une question intéressante serait de savoir si ce même schéma ( | 1) -1 ) utilisés dans la base de code que vous examinez ?

Answer 4

Il s'agit d'une façon détournée d'écrire un masque de bits. Version lisible : value == (SPINLOCK_SHARED & ~1u) .

Answer 5

Cela a été fait dans un souci de clarté, c'est tout. C'est parce que atomic_fetchadd_int() (dans par exemple sys/spinlock2.h) renvoie la valeur AVANT l'addition/soustraction, et cette valeur est transmise à _spin_lock_contested().

Notez que le compilateur C précalcule complètement toutes les expressions constantes. En fait, le compilateur peut même optimiser le code intégré basé sur des conditionnelles qui utilisent des arguments de procédure passés lorsque les procédures reçoivent des constantes dans ces arguments. C'est la raison pour laquelle le code inline lockmgr() dans sys/lock.h a une déclaration de cas.... parce que cette déclaration de cas entière sera optimisée et se transformera en un appel direct à la fonction appropriée.

En outre, dans toutes ces fonctions de verrouillage, l'overhead des opérations atomiques éclipse tous les autres calculs de deux ou trois ordres de grandeur.

-Matt