Duo-Core: Programm nur auf einer CPU laufen lassen?

[Nuclear-Ping]

Grüße,

ich teste gerade auf einem Notebook, welches einen "Intel Centrino Duo" hat, unsere Software. Grund dafür ist, dass der Besitzer des Notebooks meint, die Software würde bei ihm nicht richtig laufen, einfach hängen bleiben, Blue-Screens auslösen. Auf meinem Entwicklungsrechner und ein paar anderen Rechnern läuft der Spaß allerdings ohne Mucken. Einziger Unterschied: Wir haben keine Duo-Core-Systeme.

Auf dem besagten System hängt die Anwendung ("Keine Rückmeldung") sporatisch bei Analysen oder Optimierungen. Mal gleich am Anfang, mal irgendwann mittendrin. Hierbei werden haufen Daten über USB bzw. die Soundkarte (je nach Analysemethode) empfangen, ausgewertet, Ergebnisse aufbewahrt und zum Schluss dargestellt.

Da ich im Code keinen nachvollziehbaren Fehler finden kann und das Programm auf Single-Core-Systemen blasenfrei läuft, habe ich aus Neugier mal die Anwendung über den Task-Manager auf nur eine CPU (CPU 0) limitiert. Nun lief das Programm den ganzen Abend ohne Mucken, Hänger, Abstürze. Ich gehe mal davon aus, dass es wohl damit zusammenhängt, kann es aber nicht wirklich verstehen oder nachvollziehen. Ich hab noch eine Vermutung, dass es vlt. mit dem FastMM zu tun haben könnte, den ich in der Anwendung verwende. Werde das morgen mal testen und ihn raushauen.

Da ich jetzt nicht fragen will, wie man solche Probleme mit Duo-Core-CPUs löst (falls es nicht am FastMM liegt), frage ich, wie man einer Anwendung sagen kann, dass sie im Falle von Duo-(oder mehr)-Core-CPUs nur auf einem Core (CPU0 z.B.) läuft? Geht das überhaupt (per WinAPI vlt)?

Danke.

Mario

[hoika]

Hallo,

das Stichwort für Google heisst CPU Affinity.

http://www.ait-augsburg.de/downloads.htm

Lade dir dort AB_Affinity runter.
das setzt den Interbase-Prozess auf einen bestimmten Prozessor,
der Quellcode sollte leicht änderbar sein.


Wie stand es im MSDN Journal so schön.
Multithreading nur benutzen, wenn es unbedingt nötig ist
und dann sollte mindestens die Hälfte der Entwickler
ein Doppelprozessor-System bekommen.
*seufz*


Heiko

[Bernhard Geyer]

Gründe kann es viele geben und die Fehlersuche kann ganz schön schwer sein.
Verwendet/Bindet ihr DLL's ein die mit MFC geschrieben sind. Hier hatten wir auch schon Probleme mit Mehrprozessorsystemen das der TCP/IP-Stack der MFC-Implementierung (AFAIK war's ne 5 oder 6er-Version) nicht Mehrprozessorsicher ist (TCP/IP-Messages gingen verloren).

[QuickAndDirty]

Wir hatten da Problem auch mit einem Programm das Daten über einen Seriellen COM pollt.
Gab da voll geniale Effekete mit Dualcore Sytsmen wie etwa Vertauschte!!!! Zeichen im
Datenstrom. Ich weiß nicht warum man so eine Hardware entwickelt die die
Kommunikation mit der Peripherie stört aber seis drumm.

Es gab da 2 Lösungen:
1. Schlechte Lösung: Im bios einen Kern lahmlegen :))))))))
2. Gute Lösung: Das Fenster/Programm auf einen der Kerne Festlegen.
http://www.delphipraxis.net/internal...ct.php?t=90209

[Bernhard Geyer]

Zitat:

Zitat von QuickAndDirty

Gab da voll geniale Effekete mit Dualcore Sytsmen wie etwa Vertauschte!!!! Zeichen im
Datenstrom. Ich weiß nicht warum man so eine Hardware entwickelt die die
Kommunikation mit der Peripherie stört aber seis drumm.

Die Frage ist aber ob die HW das Problem ist (Eher unwahrscheinlich) oder irgendein SW-Bestandteil (z.B. irgendwelche eingesetzten Seriellen Komponenten) oder das Betriebssystem hier ein paar unterschiede aufweist (z.B. Messagereihenfolge anders, wobei aber nie eine Reihenfolge garantiert wurde).

[Nuclear-Ping]

Danke für die ganzen Tipps. Freut mich, dass es per API geht, die Zuweisung eines Prozesses festzulegen.

@Hoika: Danke, aber InterBase nutzen wir nicht. ;)

:cheers:

[hoika]

Hallo,

du sollst ja auch nur den Quellcode (in der dpr)
benutzen, der ist dort fest auf den Prozess IBSERVER.EXE gesetzt,
das könntest du ja ändern .. ;)


Heiko

[Robert Marquardt]

Werden Threads im Programm benutzt? Wenn ja, dann die Synchronisierung sicherstellen.
FastMM sollte keine Probleme bereiten. Wenn der kracht, dann weil ein Fehler im Programm ist, den der Borland-Manager bisher verdeckt hat.

[Nuclear-Ping]

An den betroffenen Stellen sind keine Threads im Spiel.

@Hoika: Achso. Ich denke http://www.delphipraxis.net/internal...ct.php?t=90209 tuts auch. ;)

[Robert Marquardt]

Zitat:

Zitat von Nuclear-Ping

An den betroffenen Stellen sind keine Threads im Spiel.

Wers glaubt. Es koennen Threads in DLLs oder Komponenten sein, die nicht beruecksichtigt sind.
Mal mit einem Prozessbeobachtungstool zuschauen.

[Nuclear-Ping]

Ok, keine von mir explizit initiierten Threads. ;)
Es ist z.B. nur eine Aufnahme per BASS die gestartet wird und die Callback-Routine halt dazu. Wie schon gesagt läuft der Spaß auf Single-Core-Systemen 24/7 blasenfrei. Nur bei Duo-Core-Systemen ohne explizite Affinitätszuweisung auf einen Core steigt er halt willkürlich aus.

[DGL-luke]

BASS läuft ganz sicher threadig.

[Robert Marquardt]

Na da haben wir doch schon einen hoechst verdaechtigen Thread. Irgendwo muss naemlich ein Thread laufen der den Callback ausfuehrt.
Da lohnt es spezifisch auf BASS-Probleme mit Dual-Cores zu suchen. Google ist dein Freund.

[Nuclear-Ping]

Google ist in dem Fall nicht wirklich mein Freund. Die einzige Seite die ich für "BASS Dual Core Problems" gefunden hab war das Forum von BASS -> http://www.un4seen.com/forum/?topic=5102.0
Und da war die Empfehlung auch nur, per SetAffinityMask den eigenen Prozess auf eine CPU zu limitieren, "to avoid multicore common problems".

[Robert Marquardt]

Na damit ist erst mal klar das BASS nicht dual-core-fest ist.

[Nuclear-Ping]

Hm, mich hat grad wer auf eine Idee gebracht. In der BASS-Callback erfolgt ein Aufruf an eine andere Callback zur Darstellung eines Oszilloskops. Daran hab ich noch garnicht gedacht ... da könnte auch der Hund begraben liegen. :wall:

[Robert Marquardt]

Kann gut sein. Die VCL ist nun mal nicht threadfest.
In diesem Fall wuerde ich vorschlagen eine geeignete WM_USER Message an ein Fenster abzusetzen und dort erst den Callback zum Oszilloskop durchzufuehren. Das erledigt die Synchronisierung zum Hauptthread. Da du dich im gleichen Prozess bewegst kann LParam durchaus ein Pointer auf Daten sein. Man kann die Daten aber auch ueber eine globale Variable uebergeben.

[Nuclear-Ping]

Also ich hab das jetzt mal auf PostMessage umgestellt. Funktioniert beim Single-Core-Betrieb erstmal ganz gut. Keine Probleme auch auf der Duo-Core-Maschine.

Wenn ich allerdings die Zwangszuweisung der CPU-Affinität (nur auf einem Core zu laufen) wieder aufhebe, flackert das Osci auf dem Duo-Core und es dauert nicht lange, dann werde ich mit "Leinwand erlaubt kein Zeichnen"-Meldungen zugebombt. Setze ich die Anwendung wieder nur auf einen Core, gehts wieder. :gruebel:

[Nuclear-Ping]

Keiner eine Idee, wie ich das löse?