Verstehen von Problemen mit atomaren Lock-Operationen bei Multiprozessoren

Question

Im Falle eines Uniprozessors deaktivieren wir Interrupts vor dem Ausführen einer Lock-Operation (Lock acquire, Lock release), um den Kontext zu verhin- dern und nach der Operation wieder zu aktivieren.

Aber im Fall von Multi-Prozessor-CPU reicht es nicht aus, nur Interrupts zu deaktivieren, um die Lock-Operationen atomar zu machen.

Ich lese von einer Quelle, die, "Es passiert, da jeder Prozessor einen Cache hat, und sie können in den gleichen Speicher schreiben, auch wenn die Interrupts deaktiviert sind."

Q1. Warum ist das bei atomaren Sperren überhaupt wichtig?

Q2. Welche anderen Probleme ergeben sich bei der Implementierung von Sperrvorgängen in einer Umgebung mit mehreren Prozessoren, bei denen nur die Interrupts deaktiviert werden?

Answer 1

Nur das Deaktivieren von Interrupts ist nicht ausreichend, da die Threads, die auf Multiprozessoren laufen, gleichzeitig auf die Datenstrukturen und Codes innerhalb der Funktionen von Synchronisationsobjekten zugreifen können. Daher kann Atomizität nicht durch Deaktivieren der Interrupts erreicht werden. Beispiel: L sei ein LOCK-Objekt und L.status sei "FREE" und ein X ist ein Prozess mit vier Threads T1, T2, T3, T4 und jeder von ihnen läuft auf separaten Prozessoren P1, P2 , P3, P4.

Lassen Sie uns den Pseudo-Code übernehmen für LOCK :: acquire() ist wie folgend,

LOCK::acquire(){ 
     if(status==BUSY){ 
      lock.waitList.add(RunningThread); 
      TCB t == readyList.remove(); 
      thread_switch(RunningThread,t); 
      t.state=running;  

     } 
     else{ 
      status=BUSY; 
     } 


} 

Wenn wir nur die Interrupts zu deaktivieren, die Codes von T1, T2, T3, T4 noch auf dem entsprechenden laufen kann Prozessoren. Nehmen wir an, dass das Schloss in einem Moment frei ist.

Wenn alle Threads versuchen, die Sperre-L zur gleichen Zeit zu erwerben, ist es möglich, dass sie den Status der Sperre zur gleichen Zeit überprüfen, und in diesem Fall wird jeder der Threads finden status == "FREE", und alle Threads erhalten die Sperre, wodurch die Anwendbarkeit der aktuellen Sperrenimplementierung beseitigt würde.

Aus diesem Grund werden bei der Implementierung von Sperrobjekten für Multiprozessoren verschiedene atomare Operationen wie test_and_set verwendet. Diese atomaren Operationen würden nur einen Thread von einem Multiprozessorzugriffssperrcode gleichzeitig erlauben.