Jey, jay ich wusste es, wir beginnen uns zu streiten !
Zitat:
Natürlich kann garnicht jede CPU Operation atomic sein.
Zitat:
Falsch, sie muß es sogar sein! Du kannst die auf dem Level der Maschinensprache nicht weiter aufspalten! Wie komplex der darunterliegende Microcode ist, ist komplett irrelevant (, denn in der CPU wird jeder Opcode quasi wie eine Funktion behandelt ... bevor diese nicht zurückkehrt, gehts auch nicht weiter (1))!
Eben nicht. Komplexe Befehle beeinflussen durch den Microcode interne Statusregister und externe Addressleitung sequentiuell. D.h. innerhalb mehrer Taktzyklen ändern sich Register und Addressleitungen. Die Maschinensprache ist somit irrelevant und der Microcode ist das Argument das eine CPU eben nur sehr wenige atomare Operationen beherrscht. Betrachtet man dies unter dem Gesichtspunkt der Multiprozessorenfähigkeiten das kann es auch nicht mehr Threadsafe sein. Bei solchen Konstellationen wird durch das LOCK Prefix alle parallelen CPU's angewiesen zu schlafen, damit eben der EINE OpCode der intern aus vielen sequentiellen OpCodes im MicroCode ausgeführt wird nicht dazu fürht das sich z.b. Überschneidungen auf den Adressleitungen zum Speicher auftreten.
Zitat:
Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic.
Zitat:
Sorry, sehe ich nicht so! EAX ist 4 Byte breit, also werden 4 Byte von dieser Adresse gelesen, komme was da wolle! Das hat was mit der Breite der Operanden zu tun. Der Assembler wird sich zB weigern sowas zu machen:
Auch hier stimmt deine Annahme nicht. Wird über MOV EAX,[Address] auf Speicher zugegriffen der nicht an 4 Byte Grenzen ausgerichtet ist so entstehen durch Cachemisses zusätzliche Micro Ops. Diese wiederrum führen dazu das der Cache eventuell reorganisiert wird und da der cache eine shared Resource in einer Multiprocessor plattform ist würde das ohne LOCK zu Problemen führen.
Sogesehn sind deine Argumente genau die nötigen Argumente um meine Argumentation zu unternaumern
ABER! bevor es mit unserer Diskussion weitergeht müssen wir klären was Multithreading des Operationssystemes ist und was Multiprocessing auf Mehrprocessorensystemen bedeutet. Das eine hat mit dem anderen NICHTS zu tun solange das Threading auf Single Prozessoren Systemen läuft.
Nur auf Single Prozessoren wäre deine Annahme richtig, da dort keine andere CPU konkurrent zu aktuellen CPU an den Addressleitungen rumpfuscht. Denn dann kann innerhalb eines externen OpCodes der durch den MicroCode ausgeführt wird kein Taskswitch durchgeführt werden. Somit kann auf einem Single Prozessoren System die eine CPU nicht zur gleichen Zeit auf die gleiche Adresse zugreifen so daß es zu einer NICHT-atomaren Operation käme. D.h. eine CPU = ein Atom = alle Operationen atomar. Dies betrachtet aber nur die CPU und nicht die CPU einer Grafikkarte, nicht einen DMA Chip oder nicth einen
IDE Controller, die alle ebenfalls in den Speicher reinschreiben können. So, wird ein OpCode wie MOV EAX,[Address] durch den CPU MicroCode in mehrere Zugriffsoperationen zerlegt, da die Adresse nicht an 4 Bytes ausgerichtet wurde, dann heist das das diese 4 Bytes durch 2 gesplittete Leseoperation gelesen werden müssen. Genau dazwischen kann aber die Grafikkarte, der DMA Chip oder der
IDE Controller den noch fehlenden Speicherbereich aktualisieren. Die CPU würde im nächsten Zyklus somit in EAX einen falschen Wert zusammenbauen. Deshalb kann eine Single CPU eben nicht atomar sein.
Da ich aber NICHT der absolute Experte auf diesem Gebiet bin, interessiert mich dieser Fakt nicht. Ich gehe deterministisch vor und nehme an das das LOCK Prefix für Multiprozessoren wichtig ist, und auf Single Prozessoren kann es nicht schaden.
Gruß Hagen