Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Multithreading mit 16 Aufgaben

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 26.08.2020, 16:57    Titel: Multithreading mit 16 Aufgaben Antworten mit Zitat

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ß
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
grindstone



Anmeldungsdatum: 03.10.2010
Beiträge: 1013
Wohnort: Ruhrpott

BeitragVerfasst am: 27.08.2020, 10:54    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Sebastian
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 5934
Wohnort: Deutschland

BeitragVerfasst am: 27.08.2020, 11:41    Titel: Antworten mit Zitat

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.
_________________
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 27.08.2020, 13:35    Titel: Antworten mit Zitat

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
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 27.08.2020, 14:16    Titel: Antworten mit Zitat

Muss aber ehrlich einräumen, dass

ThreadWait TA1
ThreadWait TA2
...

es eleganter tut mit dem Kopf durch die Mauer wollen
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4340
Wohnort: ~/

BeitragVerfasst am: 27.08.2020, 16:27    Titel: Antworten mit Zitat

Kannst auch für die Thread-Handle ein Array erstellen und THREADWAIT durch eine Schleife laufen lassen. lächeln
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2479
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 27.08.2020, 21:02    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 28.08.2020, 06:55    Titel: Antworten mit Zitat

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.
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1775
Wohnort: [JN58JR] DeltaLabs.de

BeitragVerfasst am: 08.09.2020, 20:34    Titel: Antworten mit Zitat

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 ][ DeltaLab's ][ ToOFlo ][ BGB-Movie ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 08.09.2020, 20:56    Titel: Antworten mit Zitat

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.
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1775
Wohnort: [JN58JR] DeltaLabs.de

BeitragVerfasst am: 09.09.2020, 20:03    Titel: Antworten mit Zitat

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 ][ DeltaLab's ][ ToOFlo ][ BGB-Movie ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 10.09.2020, 09:30    Titel: Antworten mit Zitat

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.
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1775
Wohnort: [JN58JR] DeltaLabs.de

BeitragVerfasst am: 10.09.2020, 09:44    Titel: Antworten mit Zitat

??? .. 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 ][ DeltaLab's ][ ToOFlo ][ BGB-Movie ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 10.09.2020, 19:03    Titel: Antworten mit Zitat

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


_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4340
Wohnort: ~/

BeitragVerfasst am: 10.09.2020, 20:06    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
pzktupel



Anmeldungsdatum: 07.07.2020
Beiträge: 36

BeitragVerfasst am: 10.09.2020, 21:01    Titel: Antworten mit Zitat

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 ?
_________________
Pech in der Liebe, Glück im Verlieren !
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4340
Wohnort: ~/

BeitragVerfasst am: 10.09.2020, 22:06    Titel: Antworten mit Zitat

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. lächeln
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. happy
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1775
Wohnort: [JN58JR] DeltaLabs.de

BeitragVerfasst am: 11.09.2020, 17:34    Titel: Antworten mit Zitat

@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 ][ DeltaLab's ][ ToOFlo ][ BGB-Movie ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz