Sperrt dann der Prozessor den Speicherbereich oder wie?
Naja, die vorhandenen Cores (egal ob auf dem gleiche Chip oder verschiedenen Chips) kommunizieren über den FSB. Bei einem "interlocked" Befehlt teilt dann im Prinzip ein Core den anderen mit "ich will bitte jetzt was 'interlocked' auf dieser bestimmten Cache-Line machen", und wartet bis die anderen ihr "OK" geben. Dann führt er den Befehl aus, und teilt den anderen Cores dann mit dass er nu fertig ist. Das ganze dauert im übrigen ziemlich lange verglichen mit einem "normalen" Befehl, man sollte "interlocked" Befehle daher so selten wie möglich einsetzen, aber natürlich so oft wie nötig.
Und kann die Hardware noch mehr so abgefahrene Sachen?
"Die Hardware" kann leider viel zu wenig, d.h. zumindest normale x86 Boxen.
z.B. gibt es keine möglichkeit direkt mehr als einen Befehl in Folge "interlocked" auszuführen - was man aber oft gut brauchen könnte. Genauso wäre es für gewisse Dinge hilfreich wenn man eine Möglichkeit hätte eine Speicherzelle zu "taggen", um dann ein paar Befehle später sagen zu können "schreib xyz in die getaggte Speicherzelle, aber bloss wenn seit setzen des Tag kein anderer Core da reingeschrieben hat".
----
weil solche locks per hardware gemacht werden, sind die natürlich um zehnerpotenzen performanter als alles was das betriebssystem anbietet...
Auf Windows (Pentium 4 mit HT) braucht das:
unsigned long g_l = 0;
// ...
void foo()
{
bool ok = false;
::EnterCriticalSection(&g_cs);
if(g_l == 0)
{
g_l = 1;
ok = true;
}
::LeaveCriticalSection(&g_cs);
}
bloss etwa 3x solange wie das:
unsigned long volatile g_l = 0;
// ...
void foo()
{
bool ok = ::InterlockedCompareExchange(&g_l, 1, 0) == 0;
}
Vorausgesetzt natürlich die CRITICAL_SECTION ist "frei".
Von Zehnerpotenzen kann man also nicht ganz reden
Eine MUTEX ist allerdings wirklich um Zehnerpotenzen langsamer als ein interlocked Befehl oder auch einen CRITICAL_SECTION, weswegen man ja auch immer ne CRITICAL_SECTION verwendet wenn man nicht unbedingt die erweiterten "Features" einer MUTEX braucht.
Unter *NIX siehts ähnlich aus sofern "usermode spin-locks" verfügbar sind - die meisten PTHREADS mutex Implementierungen sind aber nen schönes Stück langsamer als eine CRITICAL_SECTION oder ein "usermode spin-lock".
