Ankündigung

Einklappen
Keine Ankündigung bisher.

Java Programm Primzahlen Check Server

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    MultiThreading evtl.? wo fängt denn Hyperthreading an?

    WebClient webclient = new WebClient
    ("http://www.schlingensiepen.com/primscheduler/");
    System.out.println(
    webclient.receiveContent());
    System.out.println(
    webclient.transmitContent("prim", "2"))

    Ist doch alles schon da was du für die Kommunikation brauchst.

    Hab jetzt nicht alles komplett durchgelesen, aber du musst doch nur

    webclient.receiveContent() auswerten, da wird dann wohl n Auftrag vom Server drinne stehen, dann halt die Primzahlen berechnen und jedesmal wenn du eine findest

    webclient.transmitContent("prim", gefundenePrimzahl.toString())

    Übrigens klasse dass euer prof sich nen Cluster zum Primzahlenberechnen zusammenbaut, erster Schritt zum Verschlüsselung knacken :D

    Achja und Java multithreading... naja in Objektorientierten Sprachen muss man sich schon gewaltig zusammenreissen um das vernünftig umzusetzen (Stichpunkt funktionale Programmierung)

    Kommentar


      #17
      Jo stimmt, danke. Wie gesagt, bin nicht mehr so in der Materie drinne. Hyperthreading war bei der i5 - i7 CPU Generation. :D

      Daher die Verwechslung.

      Btw, wenn du schon Klugscheißen musst, dann helf ihn doch wenigstens richtig. Oder war das ein "Ich staub mal ein Post ab und tu so als hätte ich Ahnung" ? ;)

      Kommentar


        #18
        Ups, falscher knopf ^^
        @sicXs ja, läuft :D

        Nein, Multithreading ist zwar vom Ding her möglich in Java, aber versuch mal mit mehreren Threads auf ein Objekt bzw. auf einen kritischen Bereich zuzugreifen (Werte verändern).

        Da gibts dann normalerweise als "einfachste" Lösung das synchronized, das hat aber zur Folge dass alle Threads synchroniziert werden, d.h. die laufen auf einer CPU, ergo wird das wieder Single-Threading.

        Kommentar


          #19
          Ähm, Multithreading zeichnet gerade OOP aus. Da man es da umsetzen kann. Und wieso zusammen reißen? Jedes (gescheite) Programm arbeitet mit Multithreading.

          Kommentar


            #20
            Ich dachte du hast Ahnung, aber das hast du wohl nicht!

            Natürlich können nicht mehrere Threads auf eine Variable zugreifen und diese Verändern!
            Na dann gute Nacht, wenn du nur diese Verwendung von Threads kennst!

            BSP? Jedes PC Spiel nutzt Multithreading.

            Kommentar


              #21
              Ich versteh das ganze Konzept so:

              - Du hast einmal den ProfServer, der steht außen vor, der erhält nur die Ergebnisse
              - Dazu hast du noch einen "lokalen" Server

              Gestartet wird alles ja in der App.java weil dort die main-methode ist:
              Server server = new Server( 3141 );
              server.startServing();

              BasisClient client = new BasisClient("localhost", 3141);

              Also Server lokal auf Port 3141, Client auch lokal, bekommt die Addresse von lokalen Server + Port.

              Der Client (BasisClient.java) ist aber mehr als rudimentär...

              Die Threads sind auf der Serverseite und zwar der BasisClientHandler und einmal der Server ( aber nur für den Socket accept, aber das ganze Connection zeugs muss dich ja nicht interessieren).

              Der macht nichts anderes als Server.handleConnection(Client);
              -> BasisServer.java
              Die ruft dann
              protected void handleLine(String line, PrintStream output)
              {
              // TODO Auto-generated method stub
              }
              auf.
              Dort musst du (man siehts auch an dem "TODO" die Methode schreiben.
              In der Oberklasse (Server.java) steht zudem:

              // TODO Weitergeben der Zeile an Tokenizer, hier einfaches echo (Rückgabe der Zeile)

              Also musst du selber n Tokenizer schreiben und wohl dann die Zeile vom Tokenizer an den Automaten weitergeben.

              Ich glaube der Server holt sich vom Webserver einen Auftrag, also muss der einen Webclient haben:
              WebClient webclient = new WebClient ("http://www.schlingensiepen.com/primscheduler/");
              System.out.println(webclient.receiveContent());

              Da kommt dann auf der Konsole:
              Calc Prim Start 4440064 End 4456448 Time 1294704894

              Also sollst du alle Primzahlen von 4440064 bis 4456448 berechnen.
              Die würd ich jetzt als Server einzelnd an die Clients verteilen.

              Wo genau und vorallem warum in ne Datei geschrieben werden soll entzieht sich mir völlig.

              Im BasisClient würd ich damit anfangen, dass ich mir ne neue Methode bastel, die ich ähnlich die server.startServing() starten kann.
              Darin ne Schleife mit nem
              while(disconnect != true){
              String line = getInput().readLine();
              }

              in line ist dann der Auftrag von deinem lokalen Server.
              Könntest auch dann ne art Protokoll (bzw Nachricht wäre "calc 2132343" für einen Auftrag oder "disc" also Disconnect Message, aber kA ob du wirklich Sockets zumachen sollst etc.

              Kommentar


                #22
                Ich hab doch gesagt, dass man da schon mehr Dinge beachten muss als einfach Threads zu starten!

                Wenn du EIN Objekt hast auf das alle Threads zugreifen werden diese dann durch synchronized auf einen (virtuellen) Kern geschoben, und Multithreading bringt dir auf einer CPU relativ wenig.

                Von daher ist ist es zwar extrem einfach als Laie einfach ganz viele Threads zu basteln und sich dann im Taskmanager n Keks zu freuen, um aber wirklich performant zu sein muss man schon deutlich mehr nachdenken.

                Wenn man Threads immer schlafen legt oder irgendwelche Erzeuger-Verbraucher Probleme modelliert wo man aktives Warten verhindern will ist ja gut, aber eine voll skalierbare (Threadanzahl) Software zu entwickeln welche verteilt irgendwas berechnet ist nicht gerade trivial.

                Toll dass du hier gleich was allgemeines wie Spiele o.ä. als Gegenbeispiel bringst, aber selber auf Java oder oo keine richtigen Beispiele liefern kannst.
                MultiThreading ist ein Riesenaufwand, auch bei Spielen, dazu kommt dass Spiele meistens in C++ geschrieben werden und dieses auch aufgrund der Möglichkeit inline C und Assembler zu schreiben bei weitem nicht so objektorientiert ist wie Java!!!!

                Java hat extreme Probleme wegen des synchronisierens, einziger weg ist meiner Meinung direkt funktional zu programmieren, wie es zum Beispiel Scala vormacht.
                Also auch Objekte grundsätzlich immutable zu machen, dadurch verliert man jedoch viele "Vorteile" der oo-programmierung.
                Java ist für Single-Core Umgebungen entwickelt worden und wird wie alle OO-Sprachen wohl in Zukunft Probleme bekommen.

                Kommentar


                  #23
                  kann cih so bestätigen
                  primzahlen waren damals auch eine der ersten übungen
                  später haben wir dann primzahlenermittlung mittels threads gemacht
                  der aufwand ist einfach riesengroß udn die fehlersuche mit race conditions und syncronized einfach nru haarzerstreubend

                  Kommentar


                    #24
                    MurkZ postete
                    Ich hab doch gesagt, dass man da schon mehr Dinge beachten muss als einfach Threads zu starten!
                    Wo hast du das gesagt? Du hast nur folgendes gesagt und das ist schlichtweg falsch.

                    MurkZ postete
                    Nein, Multithreading ist zwar vom Ding her möglich in Java, aber versuch mal mit mehreren Threads auf ein Objekt bzw. auf einen kritischen Bereich zuzugreifen (Werte verändern).

                    Da gibts dann normalerweise als "einfachste" Lösung das synchronized, das hat aber zur Folge dass alle Threads synchroniziert werden, d.h. die laufen auf einer CPU, ergo wird das wieder Single-Threading.
                    Synchronized "locked" nur eine Methode, da diese auf eine Variable des Objektes zB zugreift. Und diese vor Veränderungen anderer Thread schützt. Ja es kann nur ein Thread drauf zugreifen. Aber Multithreading ist etwas ganz anderes! Synchronized ist nur die Lösung eines Problems. Mehr nicht.

                    Quelle

                    MurkZ postete
                    Wenn du EIN Objekt hast auf das alle Threads zugreifen werden diese dann durch synchronized auf einen (virtuellen) Kern geschoben, und Multithreading bringt dir auf einer CPU relativ wenig.
                    Wo hast du das denn her? Und wer hat nur n Single-Core CPU in unserer Zeit?

                    MurkZ postete
                    Von daher ist ist es zwar extrem einfach als Laie einfach ganz viele Threads zu basteln und sich dann im Taskmanager n Keks zu freuen, um aber wirklich performant zu sein muss man schon deutlich mehr nachdenken.
                    Hättest du wirklich Ahnung, dann wüsstest du, dass Multithreading, also Thread zu erstellen, die zB eine Variable mit Synchronized verändern, oder eben mit "wait" und "joins" arbeiten, wirklich sehr sehr schwer ist. MmN wenn nicht sogar das schwerste Thema in der OOP.

                    MurkZ postete
                    Wenn man Threads immer schlafen legt oder irgendwelche Erzeuger-Verbraucher Probleme modelliert wo man aktives Warten verhindern will ist ja gut, aber eine voll skalierbare (Threadanzahl) Software zu entwickeln welche verteilt irgendwas berechnet ist nicht gerade trivial.
                    Mhh oben schreibst du noch, es kann jeder Laie. Bzw, verteilte Berechnungen, das ist trivial. Da die einzelnen Thread unabhängig voneinander arbeiten und nicht auf gleiche Variablen zugreifen müssen! Erst wenn ein "Erzeuger-Verbraucher" Problem auftritt, wirds schön. Denn da müssen sich die Thread gegenseitig aufwecken. Aber ok!

                    MurkZ postete
                    Toll dass du hier gleich was allgemeines wie Spiele o.ä. als Gegenbeispiel bringst, aber selber auf Java oder oo keine richtigen Beispiele liefern kannst.
                    MultiThreading ist ein Riesenaufwand, auch bei Spielen, dazu kommt dass Spiele meistens in C++ geschrieben werden und dieses auch aufgrund der Möglichkeit inline C und Assembler zu schreiben bei weitem nicht so objektorientiert ist wie Java!!!!
                    Damit du es halt verstehst! Anscheinend waren dir ja Spiele "unbekannt". Mhh wie wäre es mit Windows? Oh ja, ist ja auch kein BSP... Ok wie ist das mit dem hier: Thread A überwacht einen Ordner auf Dateien. Ist eine Datei vorhanden, wird diese an Server geschickt. Thread B Erstellt solche Dateien. Zu abstrakt? OnlineBanking: Du erstellt eine Überweisung -> Thread B Erstellt Datei mit Informationen im Ordner. Thread A findet eine neue Datei, öffnet diese, ließt Daten aus und führt nächste Aktion aus. Multithreading? Ja! Warum? Stell dir vor, 1 Million Menschen wollen gleichzeitig überweißen. Glaubst du sie freuen sich, wenn einer nach dem anderen dran kommt? Oder ihre überweisungen, eins nach dem anderen abgehandelt wird?

                    So oder so in der Art, kann man was lösen. Viele wege führen nach Rom.

                    MurkZ postete
                    Java hat extreme Probleme wegen des synchronisierens, einziger weg ist meiner Meinung direkt funktional zu programmieren, wie es zum Beispiel Scala vormacht.
                    Also auch Objekte grundsätzlich immutable zu machen, dadurch verliert man jedoch viele "Vorteile" der oo-programmierung.
                    Java ist für Single-Core Umgebungen entwickelt worden und wird wie alle OO-Sprachen wohl in Zukunft Probleme bekommen.
                    Deine Meinung! Hat ja bis jetzt nichts gebracht, meiner Meinung nach...
                    Ich musste wirklich googeln, was die Bedeutung von immutable ist.

                    Quelle

                    Könntest du dich nun bitte entfernen?

                    Danke!

                    Kommentar


                      #25
                      Sorry, aber ich glaub das ist einfach zu hoch für dich oder du bist einfach noch nicht weit genug ins Programmieren eingestiegen, dass dir die Probleme von Multithreading im Hinblick auf parallele Programmierung was sagen.

                      Zu deinem synchronized, wait etc., das ist nun erstens nicht wirklich schwierig und zweitens nur ne Technik, die Methode Parallelen Programmierens ist noch ganz was anderes, ein Konzept!

                      Du scheinst zwar die Technik hinter Threads in Java verstanden zu haben, aber warum man das macht leider nicht.

                      Und zu deinem Online-Banking Beispiel:
                      Wenn auf nem Konto gaaaanz viele Operationen laufen, die durch gaaaanz viele Threads ausgeführt werden, die dann den Kontostand ändern...

                      Die Methode setKontostand() ist synchronized, das heisst jeder dieser gaaaaanz vielen threads muss sich anstellen bis er den Monitor auf das Objekt erhält.
                      Während einer der gaaaanz vielen Threads also arbeitet, können die andere nur noch eins machen, nämlich NIX, weil die auf den Monitor warten.

                      Und jetzt erzähl mir mal, wo das performant ist.
                      Du hast zwar gaaaanz viele Threads, aber nur einer kann arbeiten zur Zeit, also hast du effektiv Single-Threading.

                      Wobei das Konto auch leider für parallele Programmierung ein schlechtes Beispiel ist, weil es schwer umzusetzen ist, Stichpunkt Monad.

                      Achja und das mit der Single-Core CPU ist einfach ein Verschreiber, meinte Core in diesem Fall.

                      Dass die Threads auf einem Core dann laufen habe ich irgendwo aufgeschnappt, find ich jetzt keien Quelle zu, aber es kommt aufs selbe hinaus, ob die nun in ner Queue sind oder physikalisch auf dem gleichen Core.

                      Kommentar


                        #26
                        MurkZ postete
                        Sorry, aber ich glaub das ist einfach zu hoch für dich oder du bist einfach noch nicht weit genug ins Programmieren eingestiegen, dass dir die Probleme von Multithreading im Hinblick auf parallele Programmierung was sagen.
                        Rofl Kartoffel. Ich hab eine 3 jährige Ausbildung vorzuweisen, mit Zertifikat des Jahrgangsbesten. Was hast du? Ahnung? Ich lache. Du willst Objekte "immutable" machen. Damit man deren Variablen nicht ändern kann. So. Du nimmst der OOP ihre Eigenschaft. Objekt-Orientiert. Man erzeugt Objekte, die man wieder verwendet. Indem man zB den Namen eines Profils eines RM Users ändert, ändert man die Membervariable des Objekts "Users", welches ein KONKRETES Objekt ist. Jedes Profil eines RM-Users ist sogesehen ein "Objekt" in der Datenbank. Du willst jedesmal die Daten auslesen und ein neues Objekt erstellen, wenn jemand seine Daten ändert? Super! Du bist gefeuert würde jeder Chef sagen.


                        Oh man, du machst hier wirklich einen auf cool! Ehrlich!

                        MurkZ postete
                        Zu deinem synchronized, wait etc., das ist nun erstens nicht wirklich schwierig und zweitens nur ne Technik, die Methode Parallelen Programmierens ist noch ganz was anderes, ein Konzept!
                        Was habe ich geschrieben? Achja.

                        sicXs postete
                        Synchronized "locked" nur eine Methode, da diese auf eine Variable des Objektes zB zugreift. Und diese vor Veränderungen anderer Thread schützt. Ja es kann nur ein Thread drauf zugreifen. Aber Multithreading ist etwas ganz anderes! Synchronized ist nur die Lösung eines Problems. Mehr nicht.
                        Aber danke, dass du anscheinend auch "lesen" kannst!

                        MurkZ postete
                        Du scheinst zwar die Technik hinter Threads in Java verstanden zu haben, aber warum man das macht leider nicht.
                        Wie mir scheint, hast du Java und OOP nicht verstanden. Und den Rest schon garnicht.

                        MurkZ postete
                        Und zu deinem Online-Banking Beispiel:
                        Wenn auf nem Konto gaaaanz viele Operationen laufen, die durch gaaaanz viele Threads ausgeführt werden, die dann den Kontostand ändern...
                        Du bist irgendwo hängen geblieben! Mehr fällt mir nicht ein :)
                        Ich habe nirgends geschrieben, dass MEHRERE Threads auf EINEN Kontostand zugreifen und diesen ändern. Nein! Was kannst du eigentlich ausser Schimmeln?

                        MurkZ postete
                        Die Methode setKontostand() ist synchronized, das heisst jeder dieser gaaaaanz vielen threads muss sich anstellen bis er den Monitor auf das Objekt erhält.
                        Während einer der gaaaanz vielen Threads also arbeitet, können die andere nur noch eins machen, nämlich NIX, weil die auf den Monitor warten.
                        Da haben wir doch das Problem. Du! Nicht die Methode ist "synchronized" sondern das Objekt. Denn es kann nur ein Benutzer gleichzeitig eingeloggt sein. Es kann nur ein Benutzer seine Daten ändern. Ein Benutzer kann von seinem Konto aus eine Überweisung führen... usw... Du verstehst es anscheinend nicht. Es muss kein Thread warten. Da es Millionen Objekte gibt, jedes entspricht einen "Kunden". DAS ist OO. Nichts anderes. Kapisch? Jeder "Mitarbeiter" (Thread damit du es verstehst), kümmert sich um EIN Kunden. Wie im richtigen Leben.

                        MurkZ postete
                        Und jetzt erzähl mir mal, wo das performant ist.
                        Du hast zwar gaaaanz viele Threads, aber nur einer kann arbeiten zur Zeit, also hast du effektiv Single-Threading.
                        Erzähl ich doch garnicht, du erzählst doch hier den Käs... Btw, du hast wohl zum ersten mal recht. Das wäre nicht effektiv. :)

                        MurkZ postete
                        Wobei das Konto auch leider für parallele Programmierung ein schlechtes Beispiel ist, weil es schwer umzusetzen ist, Stichpunkt Monad.
                        Mhh ja. Dann frag ich dich. Wann wir endlich Onlinebanking bekommen? Wie lange müssen wir darauf warten? Oder machen die es von wegen "wer zu erst kommt, mahlt zu erst"? Und wenn 5 Millionen Menschen vor mit überweisen wollen, muss ich eben die 10 Minuten warten? Fällt mir nie auf.

                        MurkZ postete
                        Achja und das mit der Single-Core CPU ist einfach ein Verschreiber, meinte Core in diesem Fall.
                        Es war so oder so falsch. Red dich jetzt nicht raus. Danke.

                        Falls du mich oben schon hast melden lassen, sorry, aber ich hab mich verschrieben. Werde es später korrigieren!

                        MurkZ postete
                        Dass die Threads auf einem Core dann laufen habe ich irgendwo aufgeschnappt, find ich jetzt keien Quelle zu, aber es kommt aufs selbe hinaus, ob die nun in ner Queue sind oder physikalisch auf dem gleichen Core.
                        Hää?? Bitte was? Erklär das mal. Also Hören-Sagen kennt man ja. Kommt viel Scheiss bei rum! Also, ich glaub ich kopier den Text und geb ihn meinen ehemaligen Ausbilder, damit er was zum lachen hat. Eine Queue ist eine Schlange! First in, First out. Was hat das mit "physikalisch auf dem gleichen Core" zu tun?

                        Kommentar


                          #27
                          kommt mal wieder runter, habt eh nur halbwissen -.-

                          multithreading ist heutzutage nichts aussergewöhnliches mehr auf verteilten cores und wird ja auch bei den neuen spielen meist so genutzt. ist zwar nur bedingt effizient, aber immerhin ein 1. schritt in die "richtige" parallelität.

                          zu dem bankenbeispiel muss ich dem murkz recht geben, nicht das objekt ist gelocked (laut siXcs, der mir ziemlich aggressiv vorkommt oO) sondern wirklich nur die methode die "synchronized" ist.. du kannst den Namen des Kunden ändern als Berater (kunde.setName(x)), aber in dem moment in dem der Kunde am Geldautomat Geld abhebt (kunde.setKontostand(-100)) kann der Bank-Mitarbeiter zur gleichen Zeit der Ehefrau des Kunden an der Kasse KEIN Geld auszahlen obwohl diese bevollmächtigt ist :) weil die methode "setKontostand" locked ist...

                          Kommentar


                            #28
                            Und du bist der Profi? Na los, teile deine geistigen Ergüsse mit uns. :)

                            Kommentar


                              #29
                              nein, profi bin ich keinesfalls... schon gar nicht bei diesem recht schwierigen und nach heutigem stand "unlösbaren" problem... versucht euch einfach weniger zu profilieren... bin ja stolz auf euch:)

                              Kommentar


                                #30
                                Jason Lee postete
                                kommt mal wieder runter, habt eh nur halbwissen -.-

                                multithreading ist heutzutage nichts aussergewöhnliches mehr auf verteilten cores und wird ja auch bei den neuen spielen meist so genutzt.
                                Etwas anderes habe ich auch nicht gesagt.

                                Jason Lee postete
                                ist zwar nur bedingt effizient, aber immerhin ein 1. schritt in die "richtige" parallelität.
                                Du bist raus! Bedingt effizient. Unfassbar. Hast du jemals ein Programm entwickelt, dass über "Hello World" hinausgeht?

                                Lesen

                                Hardware erlaubt Multithreading? --> CPU kann besser genutzt werden. Punkt 1.
                                Leeeeesen Wer braucht schon Multithreading?

                                Oder

                                Ich sage es noch einmal. Ohne Multithreading wäre nahezu jedes Spiel unmöglich zu spielen. WoW, CS, SC2, Diablo usw... Jedes dieser Spiele, überprüft im Hintergrund das Verzeichnis auf "Cheats", veränderte Dateien. Mhh stellt euch das mal ohne Multithreading vor... Ja...

                                Jason Lee postete
                                zu dem bankenbeispiel muss ich dem murkz recht geben, nicht das objekt ist gelocked (laut siXcs, der mir ziemlich aggressiv vorkommt oO) sondern wirklich nur die methode die "synchronized" ist.. du kannst den Namen des Kunden ändern als Berater (kunde.setName(x)), aber in dem moment in dem der Kunde am Geldautomat Geld abhebt (kunde.setKontostand(-100)) kann der Bank-Mitarbeiter zur gleichen Zeit der Ehefrau des Kunden an der Kasse KEIN Geld auszahlen obwohl diese bevollmächtigt ist :) weil die methode "setKontostand" locked ist...
                                [/quote]

                                Jo bin aggresiv. Ich vertrete die Meinung, wenn man keine Ahnung hat, einfach mal... Ne?

                                "sondern wirklich nur..." Du bist wohl der Gott in Sachen Programmierung! Natürlich kann man sich darüber streiten. Viele wege führen nach Rom! Zum 3. Mal. Wenn ihr wirklich Ahnung hättet. Wüsstet ihr, dass man ein Problem, auf viele Arten lösen kann. Aber anscheinend les ihr manchmal die CT, iwo ein Artikel, oder versucht euch selbst das Programmieren bei zubringen und habt nichts zustande gebracht, ausser eben zu lesen.

                                Mag zwar sein, dass es im Bezug auf das OnlineBanking, ein Problem vorhanden ist, da eben dieser spezielle Fall, man hebt Geld ab, aber Berater ändert Namen (was ja eigentlich unlogisch ist, gibts eine Namensänderung, ruft der Kunde an und der Berater ändert den Namen sofort. Und der Kunde hebt wärend dessen ja kein Geld ab. Aber wir leben wohl in deiner Welt! Nungut.)

                                Aber dann geb ich dir ein Beispiel. Mann ruft an, will den Namen ändern lassen. Berater macht das. Frau ruft im selben Moment an und will auch den Namen ändern. Anderer Berater macht das selbe und will auf das selbe Objekt zugreifen. Tjo, schon hast du eine Exception. Also MUSST du das Objekt locken.

                                Und jetzt hör bitte auf, so zu tun, als hättest du mehr als Grundwissen...

                                //Edit
                                Natürlich MUSS man das Objekt nicht zwangsläufig locken. Man könnte beim Abruf der Methode eine boolesche Variable abfragen "isUsed". Wenn true, kann eben diese Methode nicht benutzt werden, dafür aber die anderen. Wie du siehst, kann man es auf viele Arten angehen. Aber was erzähl ich Mister Gates. :)

                                Kommentar

                                Lädt...
                                X