Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 26.08.2020, 16:57 Titel: Multithreading mit 16 Aufgaben |
|
|
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 |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 27.08.2020, 10:54 Titel: |
|
|
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! |
|
Nach oben |
|
|
Sebastian Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 27.08.2020, 11:41 Titel: |
|
|
grindstone hat Folgendes geschrieben: | Kommt drauf an, was genau da synchron gehalten werden soll. |
Genau, das ist die Frage.
Vermutlich geht es um gleichzeitige Lese- und / oder Schreibzugriffe auf Datenstrukturen, die alle Threads gemeinsam nutzen?
Vielleicht meinst du die Koordination mittels MUTEX?
pzktupel hat Folgendes geschrieben: | 16 Threads unter einem FB-Programmaufruf synchron halten |
An sich ist ja gerade das Schöne, dass die Threads nebenläufig und unabhängig voneinander arbeiten. _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 27.08.2020, 13:35 Titel: |
|
|
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 |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 27.08.2020, 14:16 Titel: |
|
|
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 |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 27.08.2020, 16:27 Titel: |
|
|
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. |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 27.08.2020, 21:02 Titel: |
|
|
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 |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 28.08.2020, 06:55 Titel: |
|
|
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 |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 08.09.2020, 20:34 Titel: |
|
|
pzktupel hat Folgendes geschrieben: | ...
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.
... |
Ohne Mutex solltest du aber auch das hier nicht tun!!
Siehe: https://www.freebasic-portal.de/tutorials/mutexe-54.html
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 08.09.2020, 20:56 Titel: |
|
|
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 |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 09.09.2020, 20:03 Titel: |
|
|
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 ] |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 10.09.2020, 09:30 Titel: |
|
|
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 |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 10.09.2020, 09:44 Titel: |
|
|
??? .. wie meinst du das? .. bzw. wie soll das gehen?
Code: |
dim shared globvar as integer
sub mythread()
'tu was
globvar += 1
end sub
threadcall mythread()
do
if globvar > 0 then exit do
loop
|
meinst du das in etwa so? Wenn ja, dann hast du hier einen wechselseitigen zugriff durch "mythread" und in der do-loop.
Bei einer "überwachung" der Threads hast du so gut wie immer das Problem des wechselseitigen zugriffs mit ausnahme von "threadwait".
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 10.09.2020, 19:03 Titel: |
|
|
Bsp. wie es vorher geregelt war
Code: | Dim As Any Ptr TA1,TA2
DIM SHARED AS UBYTE ctr1,ctr2
Sub MyThread1 (ByVal Parameter as Any Ptr)
...
ctr1=1
END Sub
Sub MyThread2 (ByVal Parameter as Any Ptr)
...
ctr2=1
END Sub
START:
TA1 = ThreadCreate(@MyThread1)
TA2 = ThreadCreate(@MyThread2)
SCHLEIFE:
IF CTR1+ctr2<2 THEN SLEEP 1000:GOTO SCHLEIFE
ctr1=0:ctr2=0
GOTO START
|
_________________ Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 10.09.2020, 20:06 Titel: |
|
|
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. |
|
Nach oben |
|
|
pzktupel
Anmeldungsdatum: 07.07.2020 Beiträge: 83
|
Verfasst am: 10.09.2020, 21:01 Titel: |
|
|
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 |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 10.09.2020, 22:06 Titel: |
|
|
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. |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 11.09.2020, 17:34 Titel: |
|
|
@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 ] |
|
Nach oben |
|
|
|