Das deutsche QBasic- und FreeBASIC-Forum

[pzktupel]

Hallo Gemeinde !

Ich programmiere diverse Siebe mit Primzahlen, was mit mehreren Threads (2,4 oder mehr) organisiert wird. Alle Thread sieben in einem Feld, was über SHARED definiert wird und durch BIT-Setzung passiert.

Mit mulmigen Gefühl stellte ich erneut fest, dass entweder ein Bit gesetzt wird, obwohl garkeins gesetzt werden sollte (ganz selten), oder es wird keines gesetzt, wenns aber sein sollte.

Ich weiß, das mir einige Grundlagen fehlen bzgl. simulatanes Handling.

Meine Frage ist, wie kann man diese Fehler beheben ?

Ich formuliere es mal knapp.

Generiere Thread1,Thread2,Thread3,Thread4

Siebe in Thread1 mit der i-ten Primzahl, wobei i=1,5,9,13 usw
Siebe in Thread2 mit der i-ten Primzahl, wobei i=2,6,10,14 usw
Siebe in Thread3 mit der i-ten Primzahl, wobei i=3,7,11,15 usw
Siebe in Thread4 mit der i-ten Primzahl, wobei i=4,8,12,16 usw

Alle setzen ein BIT in einem Masterfeld im Hauptteil.

Nach der Auswertung kommen zu <0.1%? Fehler.
Ein 2.ter Testlauf liefert nur zu 99.99% identische Werte.

Was gibt es für Befehle, die ein gleichzeitiges Zugreifen koordinieren ?

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

[nemored]

Für Multithreading gibt es MUTEXCREATE / MUTEXLOCK / MUTEXUNLOCK / MUTEXDESTROY sowie CONDCREATE / CONDWAIT / CONDSIGNAL / CONDBROADCAST / CONDDESTROY (hier der Überblick).

Wirklich viel sagen kann ich dazu nicht; mit Mutexen habe ich nur wenig, mit Conditonal Variables überhaupt keine eigene Erfahrung. Ob die Bearbeitung in mehreren Threads aber effektiv ist, hängt davon ab, wie häufig synchronisiert werden muss. Idealerweise sollte der Thread möglichst viel eigenständig arbeiten können, bevor er die Lese-/Schreibzugriffe für andere Threads sperrt, um zu synchronisieren.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[pzktupel]

Danke erstmal.

Ich konnte das Problem eindämmen..teils lags am Code selbst, aber sehr minimal entstehen dennoch Verluste (1:1000), damit kann man leben.

Keine Verluste sind, aber eben langsamer, in 4 Arrays zu sieben und diese nach Belegung am Ende abgleichen.
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[pzktupel]

Ich muss nochmal reingrätschen.

Also es ist wie es ist, greifen mehrere Threads (bei mir 4 mit 4 echten Kernen) zum Bitsetzen auf eine Feld zu, gibt es Verluste. Nicht alle werden gesetzt. Gibt es eine Lösung für dieses Problem oder ist das einfach unumgänglich ?!

Da die Bitsetzung xfach schneller ist, als die "Einssetzung" im UBYTE-Feld, ziehe ich das vor.

Erledigt das ein Thread gibt es keine Aussetzer.
Danke!
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[nemored]

Wenn jeder Thread für sich genommen korrekt funktioniert (davon gehe ich mal aus), kann es zu den Fehlern nur kommen, wenn die Lese- und Schreibzugriffe nicht stimmen. Beispiel: Thread 1 und Thread 2 lesen den Wert der Variablen ein. Thread 1 schreibt einen neuen Wert in die Variable (durch das Setzen eines Bits), Thread 2 schreibt ebenfalls einen neuen Wert und überschreibt damit den zuvor von Thread 1 gesetzten Wert. Auch wenn Lesen und Schreiben in einem einzigen FreeBASIC-Befehl stattfindet, sind das intern in der Regel mehrere Schritte, und da die Threads "zeitgleich" bearbeitet werden, können sich die Anweisungen jederzeit gegenseitig in die Quere kommen.

Als Lösung müsstest du bei jedem Lese- und Schreibzugriff auf eine SHARED-Variable ein MUTEXLOCK durchführen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[ThePuppetMaster]

Tutorial ...
... Mutex: https://www.freebasic-portal.de/tutorials/mutexe-54.html
... Threading: https://www.freebasic-portal.de/tutorials/threading-56.html


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

[pzktupel]

Also ich komm nicht klar mit den MUTEX-Befehlen, was mein Anliegen ist.
Ich gebe mal das Sieb hier aus, nur die 4 Threads...wo muss jetzt was/wo gesetzt werden, damit bei 4 Zugriffen nix verloren geht. Hier zählt eben jede milliardste Sekunde

Das Feld A(...) ist global und über SHARED organisiert und wird mit Bitsetzung 4fach befeuert.
Immerhin wird kein Bit falsch gesetzt, also ungesiebt bleibt ungesiebt.

Das Feld A ist mal hier UINTEGER , damit 64 Bits gesetzt werden können, üblich sind aber UBYTE.

Somit im Vergleich A(800000) AS UBYTE = A(100000) AS UINTEGER

[ThePuppetMaster]

Hi,

der Code ist leider etwas unübersichtlich ... aber, wenn "A" eine Shared Variable ist, dann "um" A herum.

[pzktupel]

Puh...
Also ich kann mir eher ein Bild machen, wenn das Gewollte fehlerfrei läuft. Oftmals kann ich mir kein Bild machen, was für andere selbstverständlich ist...wenn es mir neu ist. Dieses mutexlock(...) sagt mir jetzt garnix, was in die Klammer soll, deshalb hier das komplette Sieb. Ich lese das 100mal in den Hinweisen, aber es unklar...
Unwichtige Zeilen entfernt...diente zur synchronisation zum 2. PC
Es ist ein komplexes inhaltliches Sieb, deshalb brauch ich an den wichtigen Punkten in den Threads genau den Teil, damit keine Bitsetzung futsch geht.
Denke, das ist schon anspruchsvoll...wenn zu lange Wartezeiten entstehen, bringt das ja dann auch nix mehr...da kann man auch ein Thread und viele gleiche Instanzen laufen lassen. Der ganze Teil mit dem PseudoPrimTest, würde entfallen, wenn keine Bitsetzung verloren gehen würde...so dient es der Fehlerkorrektur.

[ThePuppetMaster]

[nemored]

Kurz gesagt: du brauchst zunächst einmal ein Mutex, das du über MUTEXCREATE erzeugst, z. B.

[pzktupel]

Ich habe Ansatzweise mal sowas eingebunden, aber das wurde total langsam...daher unbrauchbar.

Ein anderer mathematischer Trick war mir eingefallen, was die Fehlerquote ohne MUTEX auf Null setzte....war auch langsamer, daher unbrauchbar.

Ich bin wieder zum alten im Moment zurück und bügel die Fehler mit einem Zusatzprogramm aus.

Der Trick war, splitte das Intervall in 4 Teile und siebe versetzt ein Teilintervall durch , rücke dann eines weiter...zu deutsch:
[in Mio]
STEP 1
Thread 1 siebt 0-12,5
Thread 2 siebt 12,5-25
Thread 3 siebt 25-37,5
Thread 4 siebt 37,5-50
STEP 2
Thread 1 siebt 12,5-25
Thread 2 siebt 25-37,5
Thread 3 siebt 37,5-50
Thread 4 siebt 0-12,5
STEP 3
Thread 1 siebt 25-37,5
Thread 2 siebt 37,5-50
Thread 3 siebt 0-12,5
Thread 4 siebt 12,5-25
STEP4
Thread 1 siebt 37,5-50
Thread 2 siebt 0-12,5
Thread 3 siebt 12,5-25
Thread 4 siebt 25-37,5

Ist aber eben auch wieder langsamer, leider.
Das Programm ist mit der Aufgabe auf 2 PCs rund 5 Wochen beschäftigt...da zählt jede Verbesserung.

Konkret , die Primzahlzwillinge auf Rekordlücken bis 10^17 anzuheben....
https://pzktupel.de/RecordGaps/GAP02.php
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[ThePuppetMaster]

Also, ich habe mir jetzt mal deinen Sourcecode angesehen und muss dir leider ein paar Punkte nennen.
Ist keinesfalls böse gemeint, also, bitte nicht falsch verstehen.

1. Bitte arbeite mit mehr abstand ... Deine Quellcodezeilen sind fast ohne SPACE. Das macht es EXTREM schwer ihn zu lesen und die übersicht zu behalten.

[pzktupel]

Danke erstmal für Deine Zeit für mich,
es ist viel nachzulesen um es zu verstehen.

Mit den Mehrdimensionen arbeite ich auch manchmal...aber es gibt oft Laufzeitunterschiede. Nehme aus Prinzip immer die schnellste , weil diese Programme dann richtig Wochen durchziehen.

LG

Nachtrag: Ich habe es weitesgehend eingebunden und auch in etwa verstanden. Leider lässt es sich so nicht kompilieren.

[pzktupel]

Fazit:
Ich habe das Programm zum laufen bekommen und auch wieder mehrere Varianten der Organisation durchgespielt. Wieder etwas dazu gelernt.
Offen bleibt, wie ich einen Indexwert sauber übergebe
Zur Not hatte ich:

[nemored]

[pzktupel]

Ich erhalte immer einen Fehler beim kompilieren
> 2GAP1mu_tpmb.bas(214) error 28: Expected pointer, before ')' in 'T_ID(ix) = ThreadCreate(@MyThread,CPtr(Any Ptr, ix))' <

Ich habe doch das alles so 1:1 übertragen....

[hhr]

Versuch mal Ulong anstelle von Ubyte:

FOR ix AS ULONG = 0 TO 3

[pzktupel]

Selbige Fehlermeldung
error 28: Expected pointer, before ')' in 'T_ID(ix) = ThreadCreate(@MyThread,CPtr(Any Ptr, ix))'
_________________
Umfangreichste Angaben zu Primzahl k-Tupel
https://www.pzktupel.de/ktuplets.php

[hhr]

Bei 32 Bit funktioniert Ulong, bei 64 Bit Ulongint im Beispielprogramm der Dokumentation. Vielleicht sollte man deshalb Integer wählen.