XProfan

- Page 1 -

Andreas
Gaida

Hi!
Ich finde Threads sehr sinvoll in bestimmten bereichen wie etwa TCP/IP Programmazione.
Wenn man mehrere File gleichzeitig versenden will kann man das mit Threads meiner meinung nach viel einfacher realisieren als ohne . Z.B wenn man einen MD5 Checksume von einer File braucht die etwas grösser ist dauert das schon mehrere Sekunden in der das Programm nur damit beschäftigt ist sie zu erstellen und so keine anderen Anfragen bearbeiten kann.Da der Anteil der Computer mit mehreren Processoren oder Kernen in den nächsten Jahren ansteigen wird ist es auch per die entwicklung von Programmen die hoche Rechenleistung benötigen sicherlich vom Vorteil sein sie Multithreating fähig zu machen.
Ich würde es auf jedenfall sehr gut finden wenn es possibile wäre XProfan Multithreatingfähig zu machen
wobei es mir durchaus klar ist das Threads nicht immer und überall sinvoll sind und sie nur aus just for fun zu verwenden warscheinlich mehr aufwand bedeutet als sie nutzen bringen.

MfG
Andreas

Athlon X2 4800 , 2GB Ram , GeForce 7800GT
Windows XP Pro , XProfan 10 und 11 , Profan2Cpp 1.6b

25.04.2006 ▲

Nico
Madysa

Dieses Problem verstehe ich Profan-Anfänger nicht so recht.
Ich meine:
Könnte man nicht einfach 2 Exen schreiben, und die gewünschte so abändern, dass sie nicht eigenständig laufen kann? Man potuto sie z.B. so programmieren, dass sie ein Password als Kommandozeilenparameter necessario, den nur das Hauptprogramm kennt.
Das wäre die meiner Meinung nach einfachste Variante, aber wie gesagt, ich bin noch ein
Profan-Anfänger.

Nico Madysa

Wenn ihr ein Profan-Compilat an eure Exe übergebt, habt ihr einen Thread (fast, ist ein Process). Nur noch eine
Kommunikation einbauen und Fertig.

Richtig Thomas, und per die Kommunikation gibts pipe.create

Clemens
Meier

Hi iF, wie ich gerade bei der Verfolgung Was zum Himmel ist ein Pipe festgestellt habe, hattest du auch schon im Jahr 2005 keine Zeit

Unter anderem liest man zur Pipe:
[quote:a328548b23]Wenn sich ungetimed unterhalten wird ist die Kommunikation wohl possibile langsamer als getimed![/quote:a328548b23]
Mmh, weitere Documentazione zum Timing konnte ich leider nicht finden. Also rate ich einmal, wenn ich dem Client die Uhrzeit mitteile, ist die Kommunikation dann schneller ?

Wie time ich die Kommunikation zwischen Client und Server? Und wenn Du mal Zeit hast (presumibilmente noch nicht einmal in der Rente

), könntest du dann noch ein Beispiel dazu machen?

XProfan 9.1; XP SP2; FF; Editpad

RGH

[quote:92e598cbaa=TS-Soft]Wenn ihr ein Profan-Compilat an eure Exe übergebt, habt ihr einen Thread (fast, ist ein Process). Nur noch eine Kommunikation einbauen und Fertig.[/quote:92e598cbaa]
Das funktioniert zwar schon bestens seit der ersten Profanversion, ist aber bei weitem nicht so trendy, wie echte Threads, die mit Sicherheit viel aufwändiger zu programmieren wären.

Saluto
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

[quote:8d599b4723=Clemens Meier]Hi iF, wie ich gerade bei der Verfolgung Was zum Himmel ist ein Pipe festgestellt habe, hattest du auch schon im Jahr 2005 keine Zeit

Unter anderem liest man zur Pipe:
[quote:8d599b4723]Wenn sich ungetimed unterhalten wird ist die Kommunikation wohl possibile langsamer als getimed![/quote:8d599b4723]
Mmh, weitere Documentazione zum Timing konnte ich leider nicht finden. Also rate ich einmal, wenn ich dem Client die Uhrzeit mitteile, ist die Kommunikation dann schneller ?

Wie time ich die Kommunikation zwischen Client und Server? Und wenn Du mal Zeit hast (presumibilmente noch nicht einmal in der Rente

), könntest du dann noch ein Beispiel dazu machen?[/quote:8d599b4723]Wenn ich mich nicht irre liegt ein Beispiel im Paket, ich poste auch sehr oft Sources hier in der Community welche die PipeUnit nutzen. Das ganze ist lächerlich einfach! In der ODoku sind die Pipe-Befehle auch mit kleinen Sources erklärt. Mit getimet meine ich sowas: (mal so dahingekliert)
Kompilieren Markieren Separieren

settimer 100

while 1:waitinput

    case %wmtimer : piping
    wend:killtime

oder
Kompilieren Markieren Separieren

 $u thread.pcu = thread.
thread.start 1

while 1:waitinput:wend

    end

    proc thread.do

        piping

    endproc

per beides gilt:
Kompilieren Markieren Separieren

proc piping

    declare s$

    if pipe.get(pipe&)

        s$=pipe.pop(pipe&)
        reagierAufBefehl s$

    endif

endproc

proc reagierAufBefehl

    parameters s$

    if s$="...

    elseif s$="...

    endif

endproc

Ich hoffe das hilft Dir.

[quote:f7ff5323f2=RGH][quote:f7ff5323f2=TS-Soft]Wenn ihr ein Profan-Compilat an eure Exe übergebt, habt ihr einen Thread (fast, ist ein Process). Nur noch eine Kommunikation einbauen und Fertig.[/quote:f7ff5323f2]
Das funktioniert zwar schon bestens seit der ersten Profanversion, ist aber bei weitem nicht so trendy, wie echte Threads, die mit Sicherheit viel aufwändiger zu programmieren wären.

Saluto
Roland[/quote:f7ff5323f2]Nicht so Trendy - wohl wahr!

Ich nutze ständig die Möglichkeit einen unabhängigen Prozess zu erzeugen indem sich die Exe selbst mit Parameter startet. Z.B. auch in Okrea. Das diese Variante ganz hervorragend funktioniert versteht sich von selbst - etwas geschickt muß man halt mit umgehen können - aber das wäre bei Trendy-Threads ja ebenfalls der Fall.

- Page 2 -

Clemens
Meier

Ach so, du meinst also mit Timing nichts anderes, dass sowohl im Client-, als auch im Server-Prog die Pipe-Abwicklung durch eine zeitgesteuerte Prozedur ablaufen soll, damit die Kommunikation schneller funktioniert. Mmh, da kommt ja deine Thread.pcu gut.

XProfan 9.1; XP SP2; FF; Editpad

Timotheus

Echte Thrads fände ich sehr sinnvoll. Der Vorteil zu einem Prozess ist nähmlich, das sich bei einem Thread alles im Arbeitsspeicher abwickelt, und damit schneller ist. Außerdem verlagnsamen mehrere Threads das gesamte System Threads nur das eigene Programm. In Threads kann man außerdem auch auf die volle Vielfalt der bereits geladenen Resourcen Zugreifen. Ohne Threads lassen sich manche Projekte nun eben nicht verwirklichen, und deshalb fände ich es wichtig das Profan in dieser oder einer der nächsten Threads erlernt, da diese eigentlich Bestandteil jeder höheren Programmiersprache sein sollten.
Also von mir ein klares:

Timo

[quote:7c486d471b=Timotheus]Echte Thrads fände ich sehr sinnvoll. Der Vorteil zu einem Prozess ist nähmlich, das sich bei einem Thread alles im Arbeitsspeicher abwickelt, und damit schneller ist. [/quote:7c486d471b]Nein.

[quote:7c486d471b] Außerdem verlagnsamen mehrere Threads das gesamte System Threads nur das eigene Programm. [/quote:7c486d471b]Nein.

[quote:7c486d471b]In Threads kann man außerdem auch auf die volle Vielfalt der bereits geladenen Resourcen Zugreifen. [/quote:7c486d471b]Jo.

[quote:7c486d471b]Ohne Threads lassen sich manche Projekte nun eben nicht verwirklichen, und deshalb fände ich es wichtig das Profan in dieser oder einer der nächsten Threads erlernt, da diese eigentlich Bestandteil jeder höheren Programmiersprache sein sollten.[/quote:7c486d471b]Nein.

Etwas gethreadet ablaufen zu lassen kostet grundsätzlich mehr energie als es nicht zu tun, wenn man die Threads untereinander abstimmen möchte! Von einer Verringerrung von Arbeitsleistung kann keine Rede sein! Threads sind sinnvoll um zu Strukturieren, z.B. so wie es Andreas am Beispiel aufzeigte.

Probierts doch einfach mal - startet doch einfach mal einen Thread! Die Doku in MSDN ist hervorragend!

Die Geschichte der Threads ist eine Geschichte voller Missverständnisse.