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 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.

[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 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.