SYS2

• thread
• SIMD: Single Instruction Multiple Data
  • SSE, AVX

Un cache ça marche par cacheline.

On a deux cores qui executent 2 instructions. Ils mettent ça dans une cacheline commune -> False sharing
Le problème est lors du “commit” de la cacheline, les 2 cachelines risquent de ne pas être les memes -> conflits
Une solution (qui ajoute un autre problème) serait de synchroniser les cachelines entre elles.
Si la cacheline 1 vient d’être changée, alors elle prévient la cacheline 2 du changement. La cacheline 2 se synchronise avec 1 pour etre à jour et éviter tout conflit lors d’un “commit”.
Inconvénient -> vérification et/ou synchronisation à chaque changement d’une cacheline

Ne pas utiliser stat(“file”) -> entre un stat() et un open(), on a pu changer le “file”, les infos du stat() ne sont plus valides
-> utiliser fstat() à la place

On parle d’une liste (???)

Section critique:
ajout ou suppression dans la liste -> situation critique

On marque les instructions dangereuses sur la liste pour savoir si on peut faire une autre instruction en parallèle.

* marquage
instruction_dangereuse
* marquage

On ne lock pas les datas, ça n’a pas de sens.
Ce qui nous intéresse, c’est l’état de la liste.

Atomic Primitives:

• test and set -> TAS
• compare and swap -> CAS (x86)

// lock
for (; ;){
    if (v == 0){ // CAS: compare and
        v = 1;   // swap
        break;
    }
} // volatile

volatile -> ne fait pas d’optimisation à cet endroit-là

-> Attente active (CPU est en train d’attendre que la valeur soit à 0)

• Spinlock

  // lock
  for (; ;){
      if (v == 0){ // CAS: compare and
          v = 1;   // swap
          break;
      }
      sleep(0);
  } // volatile
  

• Mutex
• Semaphore -> quand on a besoin de compter
  • Count
  • Queue de process en attente
  • Dans POSIX, on a des semaphores qui marchent entre des processes

• Deadlock
• Livelock -> Deux personnes dans un couloir étroit en train de s’éviter l’un et l’autre

-> Invasion de priorité