Seite 5 von 7
Re: SWT[5]#3
Verfasst: Mi 1. Jul 2009, 23:13
von Thomas
könnte es sein dass du die cyclic-barrier verwendest? wenn ja bei mir gings damit auch nicht erst als ich join verwendet habe hats geklappt
Re: SWT[5]#3
Verfasst: Mi 1. Jul 2009, 23:18
von Chrisss
ich habs mit der CyclicBarrier gelöst und hatte damit nicht das geringste problem hm
hab bei ner size von 2000 sequentiel ~7000ms und ab 8 threads liegt die dauer bei ~3500ms, somit also t(1)/t(p) = ~2
hab aber nur nen paar werte bisher ausprobiert bis jetzt^^
Re: SWT[5]#3
Verfasst: Mi 1. Jul 2009, 23:25
von Thomas
hm berechnest du das ergebnis in der run-methode() der cyclicbarrier? ich wollte es so machen dass alle threads an der cyclicbarrier warten und hab danach mit return einfach das ergebnis ausgegeben da war das ergebnis immer noch nicht zu ende gerechnet warum auch immer. dein wert sieht aba mal richtig aus und so lang das bild dazu passt is ja alles gut^^ ich bin damit leider iwie nicht wirklich zurecht gekommen hätte die barrier auch gern verwendet um nicht mit jedem thread join() aufzurufen
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 00:03
von SLS
Thomas hat geschrieben:hm berechnest du das ergebnis in der run-methode() der cyclicbarrier? ich wollte es so machen dass alle threads an der cyclicbarrier warten und hab danach mit return einfach das ergebnis ausgegeben da war das ergebnis immer noch nicht zu ende gerechnet warum auch immer. ...
Dass dein Ergebnis nicht zu Ende berechnet wird, liegt daran, dass der Hauptfaden, der die Arbeiterfäden erstellt und startet, gleich nach dem Starten des letzten Arbeiterfadens fertig wird und dann das Ergebnis zurückgibt. Dabei sind möglicherweise ein paar Arbeiterthreads noch nicht fertig, und somit wird ein unvollständiges Bild gezeichnet. Die einfachste Lösung, die mir eingefallen ist, wenn man immer noch eine CyclicBarrier verwenden möchte, ist einfach für die Barriere anzahlThreads+1 einzustellen und auch den Hauptfaden bei der Barriere warten zu lassen vor der "return"-Anweisung. Dann gibt der Hauptfaden das Ergebnis erst dann zurück, wenn auch alle Arbeitfäden auf der Barriere warten, sprich - fertig sind.
Kurze Frage: Was ist denn bei euch bei 3a) die Kontext-Klasse aus dem Muster - Start !? Irgendwie überstimmt es nicht so genau mit den Beispielen aus der Vorlesung.
EDIT:
Wikipedia - Strategie (Entwurfsmuster) hat geschrieben:Der Kontext hält eine Member-Variable der Schnittstelle Strategie, wird aber mit einer Referenz auf das gewünschte konkrete Strategieobjekt belegt. Somit wird der Algorithmus über die Schnittstelle verwendet und dies ermöglicht auch ein Austauschen der Algorithmen zur Laufzeit.
Also sollte doch "Display" der Kontext sein.
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 00:31
von Thomas
hm aba bei start wird ja das objekt erzeugt mit createMandelbrot().
habs mal ausprobiert mit threadcount + 1 funktioniert bei mir aba trotzdem leider nicht
Code: Alles auswählen
public void run() {
double cReal;
double cImag;
for(int x = start; x < end; x++) {
for (int y = 0; y < sidelength; y++) {
cReal = translateReal(x);
cImag = translateImag(y);
result[x][y] = computeMandelbrotPoint(cReal, cImag);
}
}
try {
barrier.await();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (BrokenBarrierException e) {
e.printStackTrace();
}
}
so müsste die run methode doch aussehen oda?
naja vllt liegts wirklich daran dass ich ne innere klasse habe oder macht ihr das auch so?
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 00:43
von Dre
Hatt ich genauso... MIr hat er aber unter Gebrauch der Barrier in
immer wieder Exceptions geworfen, bis ich dann auf ne andere Alternative umgestiegen bin.
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 00:45
von Christian S.
Habe als Kontext-Klasse Start, da da ja anhand von deinen Eingabeparametern der Algorithmus gewählt wird.
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 01:02
von SLS
Anfangs hatte ich auch Start als Kontext, aber trotzdem glaube ich inzwischen, dass das falsch ist.
Guckt euch die Folie "Strategie: Beispiel aus Java" an - da wird ein LayoutManager
außerhalb des Kontexts (Container) erstellt. Es stimmt also nicht unbedingt, dass die Instanzierung einer konkreten Implementierung in dem Kontext geschieht. Es mag sein, dass die Außenwelt das macht und durch eine Methode (im Beispiel "setLayout()", in der Aufgabe - den Konstruktor von Display) die in Wikipedia genannte Member-Variable vom abstrakten Typ setzt. Start würde auch nichtmal (direkt) computeMandelbrot() aufrufen, wenn es nicht diese zusätzliche Möglichkeit gab, den Fenster nicht zu erstellen. Für mich ist also "Start" eher eine Klient-Klasse, also Anwender, als der im Entwursfmuster gennanten Kontext.
Christian S. hat geschrieben:Habe als Kontext-Klasse Start, da da ja anhand von deinen Eingabeparametern der Algorithmus gewählt wird.
Das gilt genauso gut für die Klassen MainFrame und Display - da wird der Algorithmus anhand von einem Konstruktorparameter gewählt.
@Thomas:
Bei mir ist die Arbeiterklasse auch eine innere Klasse. Deine run()-Methode sieht richtig aus bis auf die Indexgrenzen in den Schleifen. Was mich stört ist etwa dieses "sidelength" - das sollte doch "height" sein, oder? Deine Implementierung sollte ja auch mit widht!=height arbeiten können.
Ansonsten sollst du nicht nur einfach anzahlThreads+1 bei der Barriere einstellen, sondern auch barrier.await() auch vom Hauptfaden aufrufen vor "return result;"
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 01:05
von Thomas
ja sidelength hab ich height übergeben ich hab run ja in der inneren klasse und speichere in der variable sidelength die höhe das kann ich natürlich aba noch in höhe ändern. werds mal versuchen so wie du gesagt hast vllt klappts ja.
Re: SWT[5]#3
Verfasst: Do 2. Jul 2009, 01:09
von SLS
Ich drücke dir die Daumen - bei mir hat es geklappt
