Das Biegedrillknicken und der Multicore-Support


Thomas Wölfer
Thomas Wölfer

08. November 2012


Ich habe mich heute relativ lange mit einem “interessanten” Problem auseinandergesetzt: Ich hatte ein Dokument eines Kunden vorliegen und dieses Dokument enthielt unter anderem einen Stabzug, für den der Biegedrillknicknachweis geführt werden sollte.

Vom durchgeführten Nachweis gab es wiederum einen Navigationspunkte. Daran kann man schon sehen: Der Nachweis an sich (per Ergebnisse –> Bemessung) ging klaglos. Auch ausdrucken (Bildschirmvorschau, etc.) konnte man das ganze völlig ohne Probleme.

Allerdings: Wollte man den Navigationspunkt “anspringen” – also am Bildschirm wieder herstellen – dann gab es eine Fehlermeldung vom Programm. Zeigte man zuvor irgendwelche anderen Bemessungsergebnisse an – dann ging es aber auch.

Nach langer Suche wurde dann auch der Hintergrund dafür klar: Im Rahmen des Multicore-Supports haben wir bereits vor langer Zeit an verschiedenen Stellen im Programm Parallelität eingebaut: So werden beispielsweise bei der Auswahl von Ergebnissen über das Ergebnisse-Menü die Stäbe/Platten/Unterzüge etc. parallel berechnen. Genauso werden die Anzeige-Objekte für Ergebnisse parallel erzeugt: Wer also mehrere CPUs im Rechner hat, bei dem werden die auch tatsächlich benutzt, und die ganze Sache wird dann mit zunehmender Anzahl an Kernen schneller.

Allerdings sind die Pfade, wie man zu den Ergebnissen gelangt, immer ein wenig anders: Und da liegt das Problem. Bei der Erzeugung der Anzeige-Objekte, erfragen diese einfach die Ergebnisse, und wenn welche nicht vorliegen, dann werden die “On Demand” berechnet. Das ist anders als bei der Auswahl übers Menü: Hier ist sowieso klar, das in Kürze “alles” benötigt wird – also wird auch alles ausgerechnet.

Beim Biegedrillknicken geht das aber mit der “On Demand” Sache nicht wirklich, weil Teile des Programmcodes davon ausgehen, das – spätestens beim 2. Durchlauf – bereits “alle” Daten da sind – also so, wie bei der Auswahl über das Menü. Das sind sie aber nicht: Darum ist es ja “On Demand”.

Nachdem der Umbau hier wohl doch einige Zeit in Anspruch nehmen würde, habe ich den zunächst zurückgestellt. Und damit das Problem nicht mehr auftritt, wurde der Biegedrillknicknachweis aus der Parallelisierung ausgenommen: Der ist dann ab dem nächsten Update auf einer Mehrprozessor-Maschine leider wieder etwas langsamen. Zumindest so lange, bis wir das eigentliche Problem sauber lösen können…. Sorry dafür.