In einem Trehad ein Dialog auf rufen und wieder schließen ?

[Christian]

nicht thread sicher heisst das man eben synchronize benutzen muss wenn sie thread sicher wäre bräuchte würde sie intern synchronisieren.

[Euklid]

Ich kenne mich mit Threads nur sehr mäßig aus. Der Main-Thread war für die Darstellung zuständig, oder? Ansonsten darf kein anderer Thread auf die Benutzeroberfläche zugreifen oder so.

[Christian]

Doch aber nur wenn der Main Thread dabei gestoppt wird.

[Euklid]

Ok - es darf also immer maximal ein Thread auf die Oberfläche zugreifen. Macht Sinn. Danke!

[af0815]

Übrigends ist das Problem mit Threads und synchronisieren sehr gut im Buch Delphi - Win32 Lösungen (Andreas Kosch) erklärt. Dort allerdings Windows -lastig, aber trotzdem.

@Pluto:
Das Buch würde ich Dir empfehlen, das zwar Windowsseitig alle gebräuchlicheren 'fortgeschrittenen' Probleme erklärt werden. Ist zwar Delphi, aber trotzdem zu empfehlen. Zumindest findest du dort etlich Probleme beschrieben, bevor du sie selbst mühsam erfindest

[pluto]

das habe ich sogar *G*
Gut, dann werde ich da noch mal rein schauen.
ich denke ich habe das Problem gelöst.

Ich werde das Projekt demnächst mal wieder hochladen.
Ich habe jetzt mehrer Unit und Klassen draus gemacht
Damit ist der Quellcode übersichtlicher

[schnullerbacke]

Ok - es darf also immer maximal ein Thread auf die Oberfläche zugreifen. Macht Sinn. Danke!

Das ergibt sich sowohl aus dem Thread-Modell, wie auch aus der Tatsache, das wir mit Turing-Maschinen arbeiten. Das läuft ja letztlich alles Quasi-Parallel oder "round robin", also kann jeder Thread nur während eines kleinen Zeitabschnittes auf den Mainthread zugreifen.

[Euklid]

Das ergibt sich sowohl aus dem Thread-Modell, wie auch aus der Tatsache, das wir mit Turing-Maschinen arbeiten. Das läuft ja letztlich alles Quasi-Parallel oder "round robin", also kann jeder Thread nur während eines kleinen Zeitabschnittes auf den Mainthread zugreifen.

Moment - wird arbeiten mit Turing-Maschienen?

[schnullerbacke]

@Euklid

Immernoch. Ein Bus und ein Prozessor, hätte jeder Prozessor einen eigenen Bus wäre vollständige Parallelität möglich, dann wäre es auch keine Turing-Maschine mehr. Lediglich speziell Schnittstellen wie die Grafikkarte oder Massenspeicher würden da wieder zum Flaschenhals.

Mit den Transputern waren wir mal nahe dran von dem alt hergebrachten Ansatz Abstand zu nehmen, hat leider um haaresbreite nicht geklappt. Mit denen war sogar eine lineare Steigerung der Leistung möglich. Also etwa Prozessorkarte mit 8 Transputern dazu und Leistung wenn vorher 8 vorhanden waren doppelt so groß.

Schade, daß das nie kam. Die Dinger stammten aber aus Europa, sowas setzt sich in dem Markt nur schwer durch.

[Christian]

Die aktuellen Mehrkernprozessoren gehen den selben weg. Jeder kern hat zwischen den Caches, kern und Prozessorinterner Perepherie eigene Busse.
Es sollen wohl sogar eigene Speicherinterfaces geplant sein in einigen Architekturen...

[pluto]

ja. und wenn ich mehrer Thread habe greifen sie ja auch nicht alle gleichzeitig auf den mainprozess drauf zu,

[Christian]

Pluto erinner dich mal an mein Motto. Du hast noch immer nix verstanden im Bezug auf Threads.

[schnullerbacke]

@Christian

Stimmt schon, aber leider wird das zugunsten von Mehrkern-Prozessoren im Moment nicht wirklich stramm verfolgt. Ich kann mich noch an Transputer-Karten mit 4 Transputern erinnern, die man einfach in den ISA-Bus des PC's gesteckt hat. Das ganze wurde mit OCCAM (PASCAL-ähnlich, da schau her... ) programmiert.

Man stelle sich vor, nach dem Muster steckst du in einen gesonderten Prozessor-Bus, 4 x 4er-Karten mit 2 GHz Prozessoren jeweils mit 1 GB eigenem Speicher je CPU. Dann haste ne Westentaschen-Cray unterm Schreibtisch...

#Edit

Und Christian, da haben die mal wieder bei der seligen Inmos abgekupfert, aber eben noch sehr halbherzig.

[pluto]

@Christian, was habe ich denn nicht verstanden?
ich weiß das Thread nebeneinander laufen.
Ich weiß jetzt wie sie genutzt werden. Reicht das nicht ?
was muss ich dann noch wissen ?