Ich habe hier das Problem das unter Delphi6 bei verwendung einer 3th-Party-Komponente über JNI der Prozess auf Mehrsockel-Systemen abstürzt.
Wird die Anwendung mit XE6 kompiliert läuft es (kann aber jetzt noch nicht umsteigen, ist erst für nächsten Major-Releaes geplant)

Über SetProcessAffinityMask(GetCurrentProcess(), 1) könnte ich den Prozess auf einen Kern festlegen.
Das könnte aber zu Performanceproblemene führen so das ich ich alle Kerne eines Prozessors freigeben will. Also sowas in der art "SetProcessAffinityMaskForSocket(SocketNr: Integer);
Fertig dürfte es das nicht geben (Wäre natürlich schön falls doch).
Also ist die Frage wie bekommt man die bindung an einen Sockel am einfachsten hin?
Quellcode/Funktionsfragmente werden gerne genommen.

Du kannst die Anzahl der CPUs (nicht Kerne !) herausfinden. Anschließend kannst du die Zahl der Kerne auf CPU 0 (der ersten) herausfinden und deine AffinityMask entsprechend einstellen, so das dein Prozess zwar Multicore- aber nicht MultiCPU läuft.

However, im wesentlichen ist es kein Unterschied, ob ein Prozess auf einem Dual-CPU-System (2 Prozessoren mit je einem Kern) oder einem Dual-Core-System (eine CPU mit zwei Kernen) läuft. In jedem Falle sind es zwei unterschiedliche CPUs.

Folgender Code müsste das gewünschte Leisten:

markieren

Delphi-Quellcode:

procedure SetProcessAffinityMaskToOneSocket;
var
  NewMask: Int64;
begin
  GetNumaNodeProcessorMask(0, @NewMask);
  SetProcessAffinityMask(GetCurrentProcess(), NewMask);
end;

Leider kracht es immer noch.
Dann bleibt doch das während der Problematischen Funktionen ein

SetProcessAffinityMask(GetCurrentProcess(), 1);

bis wir dann auf XE6 sind

Zitat von OlafSt:

However, im wesentlichen ist es kein Unterschied, ob ein Prozess auf einem Dual-CPU-System (2 Prozessoren mit je einem Kern) oder einem Dual-Core-System (eine CPU mit zwei Kernen) läuft. In jedem Falle sind es zwei unterschiedliche CPUs.

Unterschiedliche Timings könnten schon den Unterschied machen. Allerdings würde ich der Implementierung nicht unbedingt trauen, wenn es auf Multisockets nicht läuft

[Halb-OT]

Zitat von BUG:

Unterschiedliche Timings könnten schon den Unterschied machen. Allerdings würde ich der Implementierung nicht unbedingt trauen, wenn es auf Multisockets nicht läuft

Hatte vor Jahren "in der Guten alten Zeit" den Fall das eine mit VS (noch ohne .NET) erstellte DLL beim Netzwerkverkehr mist gebaut hat wenn es ein Mulitsockel-System ist.
Auch wieder an einen Sockel (Damals Sockel = Kern) gebunden und schon waren alle Probleme verschwunden.
Hier kann ich dir zustimmen: Einen MFC/ATL-Programm sollte man nicht trauen
[/Halb-OT]