Das deutsche QBasic- und FreeBASIC-Forum

[pzktupel]

Ich habe zwar sehr bescheidene FB Kenntnisse, aber wie würdet Ihr
16 Threads unter einem FB-Programmaufruf synchron halten ?

Selber habe ich eine sehr elegante Lösung seit einem Jahr, die effektiv ist, aber wie halten es die Profis ?

Gruß
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[grindstone]

Kommt drauf an, was genau da synchron gehalten werden soll.

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[Sebastian]

[pzktupel]

Ich gebe mal etwas an, was bei meinem Vorhaben dienlich ist.

"MUTEX" und "ThreadWait" habe ich nicht in Benutzung.

8 Threads (manchmal auch 16) sieben zum Beispiel an einem Sieb gleichzeitig.

Die Verteilung ist derart, das etwa alle gleich fertig sind. Es geht erst weiter, wenn alle fertig sind.

Eine sehr elegante Lösung viel mir dazu ein.

-erstelle eine SHARED Variable wie DIM SHARED AS UBYTE tasks
-erhöhe am Ende der Aufgabe in einem Thread tasks+=1

Im Hauptprogramm selbst ,lasse es in einer Schleife warten, bis tasks MOD 8 (16) = 0 ist.

Bsp.
Start:

- Aufrufen der ganzen Threads -


Schleife:
IF tasks MOD 8>0 THEN SLEEP 1000:GOTO Schleife

tasks=0:GOTO Start


...das wäre eine Lösung, wie man beliebig viele Aufgaben synchron halten kann. Auf Grund meiner mangelnden Kenntnisse bzgl. Befehle in FB, war es eine Ersatzlösung.

Ob "ThreadWait " in alles 8/16 Instanzen auch geht, muss ich mal nachprüfen. Danke!

Grüße

pzktupel
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[pzktupel]

Muss aber ehrlich einräumen, dass

ThreadWait TA1
ThreadWait TA2
...

es eleganter tut
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[nemored]

Kannst auch für die Thread-Handle ein Array erstellen und THREADWAIT durch eine Schleife laufen lassen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[dreael]

Beispiel von mir früher:

https://forum.qbasic.at/viewtopic.php?t=8318

Zeigt aber die wichtigsten Dinge:
- Für hohe Effizienz möglichst wenig Abhängigkeiten der Threads untereinander
- deshalb kritische Abschnitte so kurz wie möglich gehalten (hier das Management, eine Teilaufgabe in Form einer Pixelzeile holen und "abliefern")
- Gesamtablauf: Worker Threads starten, Hauptprogramm-Thread soll abwarten, bis alle Worker-Threads durch sind
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[pzktupel]

Irre, was FB so alles kann...da komme ich nie hin, weil ich diese Möglichkeiten garnicht in Ewägung ziehe.

Zum Mandelbrot. Habe die Auflösung auf 1024x768 gesetzt. Das Bild war nach 5s auch schon fertig .

... ich hingegen, lasse FB seit Jahren die kleinsten n-stelligen Primzahl-k-Tupel errechnen.

https://matheplanet.de/matheplanet/nuke/html/viewtopic.php?topic=232720&start=0

Im Moment arbeiten 16 Kerne am kleinsten 500-digit-Primzahl-6-Tupel.

Das Offset X zu 10^499+X+d,d=0,4,6,10,12,16 hat nach 2 Wochen die
165'000'000'000'000'000 erreicht.
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[ThePuppetMaster]

[pzktupel]

Glaube ich, weil es manchmal vorkam, dass er ewig in einer Warteschleife hing,da wohl ein gleichzeitiger Zugriff standfand. Das mit dem Threadwait ist aber voll okay. Als alternative zu damals, hatte ich 8/16 Variablen eingesetzt und die Summe dieser musste MOD 8 oder eben 16 =0 ergeben,nachdem sie um eins erhöht wurde, falls Thread fertig. Aber heute eher umständlich.
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[ThePuppetMaster]

Es klingt, als wenn auch bei diesem ein wechselseitiger zugriff stattfindet. Die Folge -> Mutex.

Die Anzahl Variablen (8/16) ändert hier nichts an einem möglichen wechselseitigem Zugriff. Sobald ein weiterer Thread auf eine variable zugreift, besteht immer dieses Problem.

Das Hauptprogramm läuft im übrigigem in einem eigenem Thread. Sobald also mit Threadcreate / ThreadCall ein weiterer Thread erzeugt wird, muss jeder zugriff auf Variablen auf denen in beiden Threads zugegriffen wird, eine Mutex-sperre in betracht gezogen werden.


MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]

[pzktupel]

Naja, in meinem Fall hier, griff nur der eine Thread auf die eine Variable im thread selbst zu, wenn dieser bei SUB angekommen war.
Doppelt ist ausgeschlossen.
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[ThePuppetMaster]

??? .. wie meinst du das? .. bzw. wie soll das gehen?

[pzktupel]

Bsp. wie es vorher geregelt war

[nemored]

An der Stelle brauchst du halt ein Mutex. Wenn z. B. MyThread1 und das Hauptprogramm gleichzeitig auf die Variable ctrl1 zugreifen, bekommst du schnell Probleme mit der Konsistenz des Programms.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[pzktupel]

Es geht aber , man bedenke, das der Thread mehrere Minuten dauert, bis der durch ist und ob genau da in der 1s auch noch ein gleichzeitiger Zugriff wäre, ist unwahrscheinlich...und selbst wenn, dann steht das Programm und ich merke das. Aber mit Thraedwait gehts ohne der Variable auch inzwischen ganz fluffig.

Sag mal nemored, hat das mit dem affinity bzgl Corezuweisung gut geklappt ?
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[nemored]

Unwahrscheinliche Fehler sind noch schlimmer als die, die regelmäßig auftreten - sie fallen nämlich nicht auf und schlagen dann plötzlich mal hinterrücks zu.
Ich würde mich übrigens nicht darauf verlassen, dass sich bei diesem Problem nur dein Programm aufhängt; im Zweifelsfall machst du das ganze System instabil. Und auch das kann lange unentdeckt bleiben.

Wegen dem affinity - ich arbeite kaum mit Threads und kenne mich da auch nicht wirklich aus. Ich hatte die Frage nur zwecks Archivierung in meiner Wissensdatenbank (aka Kopf) gestellt - ich bin, was (insb. FreeBASIC-)Wissen anbelangt, ein Jäger und Sammler.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[ThePuppetMaster]

@pzktupel ... dieser wechselseitige Zugriff kann noch ganz andere effekte haben, als nur ein stehendes Programm.

Es kann z.B. passieren, das durch diesen zugriff andere Variablen verändert werden, und z.B. dein Programm falsche ergebnisse liefert.

Threads sind Elemente in einem Programm, die mit einer parallelität laufen, deren zeitlicher ablauf nicht unter deiner Kontrolle steht. Der Computer führt dies heutzutage meist in mehreren parallel arbeitenden Kernen aus. Sie laufen also faktisch physisch in echt parallel und nicht simuliert.

Diese Elemente können jetzt allerdings gleichzeitig auf nur einen einzigen RAM zugreifen, der eben nicht geteilt ist.

Die Problematik, welche sich ergibt ist, das z.B. das erzeugen und entfernen von Variablen entsprechende speicherbereite im RAM reserviert. Zu beachten wäre hier z.B. auch, da eine ausführende Instruktion, durch heutige CPU's bereits "erahnt" werden. Sprich ... der Computer versucht herauszufinden, wie ein programm als nächstes arbeiten könnte, und läd entsprechende Befehle gleich in blöcke in die CPU (Das ist z.B. auch eine schwachstelle, welche einen sehr bekannten und gefährlichen BUG auslöste).

Dein Programm wird also von der CPU bereits VORinterpretiert, ohne auf eine gegenseitige rücksichtnahme zu achten. Und, genau hier kann es zu Probleme kommen, wenn variablen geändert werden, dessen werte aber von von einer CPU "vorgeladen" werden.

Ein Beispiel (sehr abstrakt) wäre z.B. das zählen eines durchlaufes (do-loop) das bei erreichen eines definierten wertes (z.B. ein MOD) eigentlich die schleife verlassen sollte, aber durch einen wechselseitigen zugriff einen sprung machen könnte, und dadurch weg läuft (was eigentlich nicht möglich wäre).

Da gibt es noch viele wilde Beispiele, die im ersten blick nicht wirkoich schlimm anmuten, aber drastische effekte erzeugen können.

Sowas endet dann irgend wann in einem ... Computer -> Fenster -> Straße ... Effekt, wenn man versucht sowas zu debuggen.


MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]