Critical Section um globale Methode?

[mjustin]

Zitat von freimatz:

Müssen Clipboard Operationen nicht auch im Mainthread ablaufen? Dann wäre noch ein Synchronize nötig und könnte vielleicht auch schon alleine helfen.

Synchronize aus dem Mainthread heraus aufzurufen wird ausdrücklich nicht empfohlen:

Warning: Do not call Synchronize from within the main thread. This can cause an infinite loop.

http://docwiki.embarcadero.com/Libra...ad.Synchronize

[TiGü]

Zitat von mjustin:

Zitat von freimatz:

Müssen Clipboard Operationen nicht auch im Mainthread ablaufen? Dann wäre noch ein Synchronize nötig und könnte vielleicht auch schon alleine helfen.

Synchronize aus dem Mainthread heraus aufzurufen wird ausdrücklich nicht empfohlen:

Warning: Do not call Synchronize from within the main thread. This can cause an infinite loop.

http://docwiki.embarcadero.com/Libra...ad.Synchronize

Daher prüft man das vorher und ruft nur dann die Variante mit Synchronize auf.

[Zacherl]

Zitat von jaenicke:

In deinem Link steht doch genau die Antwort auf die Berichte über die schlechte Performance. Seit XE5 ist das behoben und schneller als eine CS.
Hier auch nochmal der Link:
https://community.embarcadero.com/bl...-monitor-38952

Zitat von TiGü:

Laut diesem Blogpost ist das seit XE5 gefixt:
http://blog.synopse.info/post/2016/0...d-applications

Oh, gut zu wissen. Hatte den Artikel noch von "damals" im Kopf und habe natürlich nur ganz unten nach Updates gesucht, bevor ich ihn gepostet habe Aber gut, dann scheint die Performance von TMonitor ja jetzt zumindest gleichwertig zur CriticalSection zu sein, wenn man einen adäquaten Wert für den SpinCount wählt.

[jaenicke]

Zitat von Zacherl:

Aber gut, dann scheint die Performance von TMonitor ja jetzt zumindest gleichwertig zur CriticalSection zu sein, wenn man einen adäquaten Wert für den SpinCount wählt.

Das passt in den meisten Fällen schon. Nur, wenn die Performance wirklich ein Problem ist, sollte man untersuchen, ob man damit etwas verbessern kann. Aber im Normalfall sollte man den SpinCount lassen wie er ist und TMonitor einfach verwenden.

[SneakyBagels]

Durch " http://www.delphipraxis.net/1373672-post10.html " bin ich hier gelandet.
ich verwende bis heute eine globale CriticalSection in meinem Programm, welche von vielen Threads aufgerufen wird, die dieselben Daten lesen und schreiben.
Überhaupt gar kein Problem und die Performance sieht auch OK aus.

Wie würde die Implementierung eines System.TMonitor aussehen?
Wie das aussieht muss ein Object geblockt werden. Welches denn genau? Meine TThread-Klasse kann man ja nicht übergeben. Was möchte TMonitor denn sonst haben?
Muss ich hier Self (TThread-Unit) übergeben oder reicht auch einfach eine Variable? Diese Variable (Klasseninstanz) enthält alles was ich im Thread schreibend ändere.

[Zacherl]

Zitat von SneakyBagels:

Wie das aussieht muss ein Object geblockt werden. Welches denn genau?

Die Objektinstanz dient TMonitor nur als Marker. Oft hat man ja eine seperate Datenklasse, auf die die Threads dann zugreifen. Hier würde ich die Instanz dieser Klasse verwenden, aber im Grunde ist es komplett egal, welches Objekt du verwendest.

[SneakyBagels]

Genau. Ich habe eine Klasse (vorher war es ein Record).
Dieser Klasseninstanz, welche nur einmalig erzeugt wird, weise ich in den Threads ein Objekt zu mit welchem ich dann weiterarbeite.
Das Objekt enthält Strings, Integers... ganz normale Dinge.

Aktuell habe ich eine globale CS welche von allen 5 Threads verwendet wird. Klappt sehr fein. Keinerlei Konflikte.
Könnte ich dann nun einfach auf System.TMonitor.Enter(meine globale Klasseninstanz) verwenden und hätte dasselbe Ergebnis nur besser?
Was müsste ich dem Enter denn übergeben, wenn ich sowas hier habe

Delphi-Quellcode:

- TTask Anfang (eine Aufgabe bei Klick im MainMenu)
 Monitor Enter
 try
  EineFunktionWirdAufgerufen
 finally
  Monitor Exit
 end;
- TTask Ende

Dort steht aktuell auch CriticalSections. Ohne ging das schief. Würde aber gerne weg von CS und hin zu Monitor nur weiß ich nicht, was ich dort als Objekt übergeben soll.

[himitsu]

Im Prinzip ist TMonitor die umgedrehte Implementation für mehrere TCriticalSection.

Du kannst in ein anderes Object eine CriticalSection rein tun und diese verwenden

Delphi-Quellcode:

TMyObject = class
  Lock: TCriticalSecition;
end;

MyObj.Lock.Enter

oder du nutzt das "versteckte" Feld in allen TObject, welches man über TMonitor ansprechen kann.

Delphi-Quellcode:

TMyObject = class
end;

TMonitor.Enter(MyObj);  // macht dann intern quasi sowas wie ein MyObj.geheimesproperty.Enter;
// und vorher noch ein IF NOT Assigned(MyObj.geheimesproperty) THEN MyObj.geheimesproperty := TCriticalSectionÄhnlichesDing.Create;

Nur den Namen "Monitor" fand ich schon immer ein bissl "irreführend".

[SneakyBagels]

Das Problem ist, dass ich für mein zuletzt genantes Beispiel keine Klasse habe und ich nur eine Funktion aufrufe.

Zitat:

TMonitor.Enter(MyObj); // macht dann intern quasi sowas wie ein MyObj.geheimesproperty.Enter;
// und vorher noch ein IF NOT Assigned(MyObj.geheimesproperty) THEN MyObj.geheimesproperty := TCriticalSectionÄhnlichesDing.Create;

Das verstehe ich jetzt nicht. Wofür denn nun Monitor und eine CS?

Ich glaube ich bleibe einfach bei CS - ist einfacher und nicht so ein Hexenwerk

[Zacherl]

Zitat von SneakyBagels:

Das verstehe ich jetzt nicht. Wofür denn nun Monitor und eine CS?

Grob gesagt ist es auch hier "egal", was du verwendest. Je nach Anwendungszweck können sich höchstens leichte Performanceunterschiede ergeben, aber was "besser" oder "schlechter" ist, kann man pauschal nicht sagen. Es sind einfach zwei verschiedene Paradigmen als Lösung für das selbe Problem.

Statt deiner CS könntest du dir einfach eine dummy TObject Instanz erstellen und darauf dann TMonitor.Enter anwenden. Macht aber nicht wirklich Sinn, weshalb ich hier wohl auch bei der globalen CriticalSection bleiben würde.