CriticalSections wie verwenden?

[jaenicke]

Zitat von Bummi:

Danke , aber wenn jeder Thread seien eigen CriticalSection erzeugt wie ist dann ein übergreifender Zugriff gewährleistet, oder da dies ja nicht eigentlich das Problem hier ist, wofür benötige ich die Threadinternen CS überhaupt?

Der übergreifende Zugriff auf die Resource des Threadobjektes passiert ja über die dazu gehörende kritische Sektion.

Das heißt es geht nicht darum, auf die selbe Resource mit verschiedenen kritischen Sektionen zuzugreifen, wie du offenbar vermutest.

[Assarbad]

Zitat von Sir Rufo:

Hmmm, das sehe ich anders, wenn ich optimal laufenden Code erzeugen will mit der maximal möglichen Performance. Natürlich wird es auch mit einer externen CS funktionieren, aber eben nicht so performant wie es laufen könnte.

Nunja, Synchronisation muß aber nunmal sein.

Meine Delphikenntnisse sind ein wenig eingerostet, aber ich sehe in deinem Code keinen konkurrierenden Zugriff zwischen den Threads. Was willst du also beweisen? Daß dein Code sicher ist, wäre zumindest damit nicht (generell) bewiesen.

Zitat von Sir Rufo:

Greift Thread A auf eine Property aus Thread B zu, dann ist die Property von Thread B ja geschützt. Somit kann es einfach keine Zugriffsfehler geben, da diese immer geschützt sind.

Die Aussage macht allerdings in der Tat Sinn, wenn ein Zugriff so wie beschrieben stattfände.

Das was ich gesehen habe wäre aber ohnehin billiger mit Interlocked-Funktionen zu machen (zumindest bei den verwendeten Datentypen).

Zitat von Bummi:

Wenn Du für jede Instanz eine eigene CS erzeugst wie soll der Zugriff dann geschützt sein.

Wenn jeder Thread seine eigene Queue hat und mit der CS schützt, dann macht es schon so Sinn. Da der Zugriff über Getter/Setter stattfindet, hat alles seine Ordnung.

Zusammenfassend:

Also, es gibt nicht nur eine Queue, somit ist die Queue auch pro Thread schützbar (so wie gezeigt).

[Sir Rufo]

Zitat von Bummi:

@Sir Rufo
Das eben macht mir Kopfschmerzen #9 b
Wenn Du für jede Instanz eine eigene CS erzeugst wie soll der Zugriff dann geschützt sein.

Aber ich muß jetzt ins Bett, gerne morgen weiter

Weil jede Thread-Instanz einen eigenen Speicherbereich hat, wo die Werte abgelegt sind.

Und ich schütze mit der Thread-internen CS den Speicherbereich der Instanz und nicht von allen Instanzen, was zwar möglich ist, aber überflüssig.

Stell dir vor ein Kühlschrank darf nur immer von einem geöffnet werden, weil sonst geht die Welt unter.

Bei deiner Methode mit der globalen CS würde das bedeuten, dass auf der ganzen Welt niemand einen Kühlschrank öffnen darf, nur weil ich gerade meinen geöffnet habe (da hatte ich aber Glück). Und erst wenn ich die Türe schließe, darf der nächste. Wenn ich böse bin, dann pfeife ich auf die Stromkosten, bzw. melde mich bei "e wie einfach" an und lasse den Rest der Welt verdursten.

Bei meiner Methode gilt das nur für den Kühlschrank, von dem ich etwas nehmen will. Alle anderen Kühlschränke interessieren mich nicht (und laut Definition auch nicht notwendig, da jeder Kühlschrank ja auch einen eigenen Speicherbereich hat, die ich nicht alle schützen muss, wenn ich meinen Kühlschrank öffne).

[Bummi]

Um bei Deinem Beispiel zu bleiben
Point.x
Point.y
in einer CriticalSection, wenn der lesende sich nicht darum schert daß es da eine (ihm unbekannte CS) gibt liest er einfach den Wert aus , egal ob der Thread es in eine CS gepackt hat oder nicht.

[Bummi]

@assabard
Wenn jeder Thread seine eigene Queue hat und mit der CS schützt, dann macht es schon so Sinn. Da der Zugriff über Getter/Setter stattfindet, hat alles seine Ordnung. aber wofür benötigt er dann ene CS?

[Sir Rufo]

Zitat von Bummi:

@assabard
Wenn jeder Thread seine eigene Queue hat und mit der CS schützt, dann macht es schon so Sinn. Da der Zugriff über Getter/Setter stattfindet, hat alles seine Ordnung. aber wofür benötigt er dann ene CS?

Weil die Queue aus einem anderen Thread-Kontext abgefragt wird (Synchronize/Queue)

[Sir Rufo]

Zitat von Bummi:

Um bei Deinem Beispiel zu bleiben
Point.x
Point.y
in einer CriticalSection, wenn der lesende sich nicht darum schert daß es da eine (ihm unbekannte CS) gibt liest er einfach den Wert aus , egal ob der Thread es in eine CS gepackt hat oder nicht.

Es muss aber zwingend in einer CS geschrieben/gelesen werden, ansonsten kann es dazu kommen, dass gleichzeitig geschrieben/gelesen wird und dann knallt es

Es ist egal, ob das von einer lokalen (im Thread verankerten) oder globalen CS geschützt wird. Es muss aber geschützt werden.

Aber wozu alles schützen, wenn ich genau bestimmen kann, was geschützt werden soll? (Sippenhaft und Singleton sind entweder nicht zulässig oder verpönt)

[Bummi]

Jepp, aber hier kommen wir wieder zu dem Punkt daß die Abfrage sich nicht für Deine lokalen CS interessiert.
wenn Du nochmals mein Beispiel aus
http://www.delphipraxis.net/156304-v...ml#post1064523
#26 heranziehst
Meine Vorstellung einer CS basiert darauf daß ein Codeabschnitt markiert Windows mitgeteilt wird. Wenn ein anderer Thread versucht diesen Codeabschnitt zu betreten wird dies nur ermöglicht wenn kein anderer Thread sich gerade darin aufhält. Wenn die Markierung jedes mal eine andere ist wie soll Windows hier eingreifen.

[Bummi]

Zitat:

Es ist egal, ob das von einer lokalen (im Thread verankerten) oder globalen CS geschützt wird. Es muss aber geschützt werden.

ich bin völlig bei Dir, aber ohne Kenntnis / Beachtung des CS wir jeder zu jedem Zeitpunkt gegf. Müll auslesen(der Speicher ist ja nicht geschützt, Windows verhindert ja nur die Reentranz in ihm bekannte CS) .

[jaenicke]

Zitat von Bummi:

wenn Du nochmals mein Beispiel aus
http://www.delphipraxis.net/156304-v...ml#post1064523
#26 heranziehst

Das ist aber ein vollkommen anderer Fall als der aus seinem Beispiel. Hier hast du eine globale Variable, auf die eben von verschiedenen Stellen aus zugegriffen wird. Das ist ja etwas anderes.

In seinem Beispiel befindet sich das Feld, auf das zugegriffen wird, innerhalb des Threads. Und es wird ausschließlich über die kritische Sektion genau dieses Threads zugegriffen. Und eben nicht durch verschiedene Threads und mehrere Sektionen. Denn beim Zugreifen verwendet auch der andere Thread die kritische Sektion des Zielthreads und nicht seine eigene.