Code classique à 2 verrouillages à jamais répandu: un faux sentiment de sécurité

链接 ：
Code sans verrou: un faux sentiment de sécurité

1. Pour éviter une course, une variable sans verrouillage doit avoir deux propriétés clés que nous devons surveiller et garantir: l'atomicité et la commande

2. les compilateurs, les processeurs et les caches adorent optimiser les lectures et les écritures, et réorganiseront, inventeront et supprimeront utilement les lectures et les écritures en mémoire, sauf si vous l'empêchez de se produire. La bonne prévention se produit implicitement lorsque vous utilisez des verrous mutex ou des variables atomiques ordonnées (C ++ 0x std :: atomic, Java / .NET volatile); vous pouvez également le faire explicitement, mais avec beaucoup plus d'efforts, en utilisant des appels API ordonnés (par exemple, Win32 InterlockedExchange) ou des barrières / barrières de mémoire (par exemple, Linux mb). Essayer d'écrire du code sans verrou sans utiliser aucun de ces outils ne peut pas fonctionner.

3. Ce n'est pas suffisant, car list.end () peut avoir des effets secondaires, c'est-à-dire que iTail est assigné avant que list.end () ne soit complet:

   list.push_back(t);	// A: add the new item
   mb();		// full fence
   iTail = list.end();	// B: publish it
   

4. La réorganisation n'est pas le seul problème. Un autre problème est que les compilateurs et les processeurs peuvent inventer des écritures, afin qu'ils puissent injecter une valeur transitoire:

   // Transformation problématique du compilateur / processeur

   if (iNext != iTail) {
         
         
     iHead = 0xDEADBEEF;
     iHead = iNext;
     t = *iHead;
   

Je ne comprends pas ce que cela signifie: iHead = 0xDEADBEEF; je
ne trouve pas ce qui suit, je ne peux que me référer au kfifo du noyau