TMonitor vs. TMultiReadExclusiveWriteSynchronizer

[AndyDF]

Hallo zusammen,

anstelle einer TCriticalSection verwende ich schon immer TMonitor, da TMonitor von der Performance her ganz gut sein soll und auch schöner einzusetzen ist.
Jetzt habe ich aber öfter den Fall, dass ich nur wenige Male die Ressource schreiben muss aber sehr oft lesen muss.

Hierzu verwende ich gerne TMultiReadExclusiveWriteSynchronizer.

Was haltet ihr davon oder würdet ihr hierfür auch TMonitor verwenden oder ganz eine andere Lösung?
Ich weiß nicht wie sich TMultiReadExclusiveWriteSynchronizer aus Performance-Sicht schlägt. Jemand Erfahrung?

[Uwe Raabe]

Praktische Performancewerte kann ich auch nicht vorweisen. Allerdings wird durch die Tatsache, daß konkurrierende Reads nicht blockieren, potentiell ein Performancegewinn zu erwarten sein. Wie das in deinem konkreten Fall aussieht, kannst nur du feststellen.

Man sollte auch bedenken, daß beide Systeme unterschiedliche Features haben. So gibt es bei TMonitor den Timeout bei Enter, das TryEnter und die Wait/Pulse Semantik.

[AndyDF]

Ja das denke ich eben auch. Da ich häufig nur lese, müsste der TMultiReadExclusiveWriteSynchronizer eine ganz gute Wahl sein.

Was ich sonst z.T. auch gerne mache:
Immutable Objects (als Interface) verwenden. Dann habe ich mit Lesen gar kein Problem und beim Schreiben wird einfach ein neues Objekt erzeugt. Dadurch braucht es überhaupt keine Sperrungen.
Das funktioniert aber hauptsächlich nur bei kleinen, einfachen Objekten. Ein TDictionary sollte ich dann doch mit einem TMultiReadExclusiveWriteSynchronizer absperren.

[himitsu]

Zitat von AndyDF:

Dadurch braucht es überhaupt keine Sperrungen.

Das stimmt so nicht ganz.

Referenzzählung bei Strings, dyn. Arrays und Interfaces wird ebenfalls über atomare CPU-Befehle vorgenommen, damit das threadsave ist,
nur wird das halt direkt vom Compiler und der internen Verwaltung vom Delphi "heimlich" mit eingebaut und man muß sich um nix kümmern.

Zitat:

häufig nur lese

Natürlich bringt es nur einen Vorteil, wenn man nicht nur häufig, sondern auch häufig aus verschiedenen Thread liest undzwar gleichzeitig.
Oder wenn das Lesen länger dauert, dann wird auch weniges gleichzeitiges Lesen Vorteile bringen

[AndyDF]

Zitat von himitsu:

Referenzzählung bei Strings, dyn. Arrays und Interfaces wird ebenfalls über atomare CPU-Befehle vorgenommen, damit das threadsave ist,
nur wird das halt direkt vom Compiler und der internen Verwaltung vom Delphi "heimlich" mit eingebaut und man muß sich um nix kümmern.

Also zumindest keine weiteren Sperrungen meinerseits.

[jaenicke]

Das kommt darauf an wie oft gleichzeitig lesend zugegriffen wird. Wenn in der Regel ohnehin nur einer gleichzeitig liest oder schreibt, ist TMonitor tendenziell etwas schneller, weil der TMultiReadExclusiveWriteSynchronizer mehr Aufwand betreiben muss.

Wenn viele wirklich gleichzeitig lesen, wird dies aber mehr als ausgeglichen, da dabei mit TMonitor jeder Thread warten müsste. Der Vorteil ist hier im Vergleich sehr viel höher, so dass ich im Zweifel den TMultiReadExclusiveWriteSynchronizer benutzen würde, wenn die Chance besteht, dass der Fall häufig eintritt, dass genau gleichzeitig gelesen wird.

[AndyDF]

Zitat von jaenicke:

Wenn viele wirklich gleichzeitig lesen, wird dies aber mehr als ausgeglichen, da dabei mit TMonitor jeder Thread warten müsste. Der Vorteil ist hier im Vergleich sehr viel höher, so dass ich im Zweifel den TMultiReadExclusiveWriteSynchronizer benutzen würde, wenn die Chance besteht, dass der Fall häufig eintritt, dass genau gleichzeitig gelesen wird.

Ok, danke! Dann bin ich da auf dem richtigen Weg. Da es auf dem Server läuft und viele Anfragen gleichzeitig kommen können/werden, wird es auch der Fall sein, dass häufig gleichzeitig gelesen wird.

[stahli]

Ich kann im Detail hier nichts beitragen.

Aber ich habe gerade bei Video2Brain ein interessantes Tutorial zum Threading in .net gesehen: https://www.video2brain.com/de/video...reading-in-net

Da werden sehr detailliert die Feinheiten, Unterschiede und Fallstricke beschrieben (bis hin zu Problemen durch Prozessoroptimierungen (Stichwort "MemoryBarrier").

Ich habe das erst mal nur interessehalber durchgesehen und kann das im Detail nicht wiedergeben.

In Bezug auf ReaderWriterLocks war das Fazit, dass man testen soll, ob dieser Lock im speziellen Fall Performancevorteile bringt.

Vielleicht wäre das Video für den einen oder anderen ja ein paar Euro wert...

[himitsu]

Im Prinzip könnte man sich doch mal einen Wrapper schreiben, der Read/Write/ReadWrite-Locks als Funktionen bietet. (ReadWrite = Write)
Und dann kann man einfach, beim erstellen der LockInstanz das einbinden, was man brauch oder mal schnell ausprobieren will.
Vom Code her ist es ja egal, ob der Code sagt "IchWillnenReadLock" und dann die jeweilige Implementation dann alles gleich lockt, wie z.B. bei der CriticalSection.

Nur der Entwickler muß halt beim Schreiben eben immer angeben, ob er lesend, schreiben oder lesend+schreiben zugreift, egal, ob es dann ausgewertet wird, aber für die Codedokumentation wäre es zumindestens ein Vorteil.

[DrTight]

Ich verweise mal auf einem anderen Thread wo TMonitor vs TCriticalSection getetstet wurden.
https://www.delphitools.info/2013/06...iticalsection/