Ringpuffer Bibliothek veröffentlicht

[himitsu]

Es ist dir ja nicht verboten eine CriticalSection, oder sonstwas hinzuzufügen.

Delphi-Quellcode:

System.TMonitor.Enter(Buffer);
Buffer.Add(irgendwas);
System.TMonitor.Exit(Buffer);

Delphi-Quellcode:

Buffer.Enter;
Buffer.Add(irgendwas);
Buffer.Exit;


type
  TRingbuffer<T> = class(Ringbuffer.TRingbuffer<T>)
    procedure Enter;
    procedure Exit;
  end;

procedure TRingbuffer<T>.Enter;
begin
  System.TMonitor.Enter(Self);
end;

Und vielleicht kommt ja Emba irgendwann in diesem Jahrhundert mal auf die Idee den Schwachsinn bei TMonitor zu reparieren.
> doppelter/missverständlicher Name und umständliche Nutzung (Wenn das eh in TObjekt integriert ist, dann doch bitte richtig)

[TurboMagic]

Hallo,

was wäre, wenn man in die Ringpuffer Klasse so wie sie jetzt ist,
je eine Enter und Leave (Exit als Name würde ich wegen dem Keyword
Exit eher nicht bevorzugen) Methode einbaut, die virtuell, leer und
inline ist aber an allen relevanten Stellen aufgerufen wird.

Wer dann eine Threadsichere Variante will, braucht nur noch von der
bisherigen ableiten und Enter und Leave passend überschreiben.

Wie wäre das?

Grüße
Turbo Magic

[himitsu]

Historisch hab ich sonst ein Leave statt Exit (Exit hier, weil's in TMonitor so heißt)


Implizit ... joar, ich war schreibfaul ... statt du überall vor Ort zu machen,
kann man auch in der Ableitung die Methoden ala Add usw. überdecken/überschreiben und dort das Enter/Exit/Leave rein tun.

Überschreiben (virtual+override) ist besser, falls man zwar die TRingbuffer_Safe<> verwendet, aber die Variable auf TRingbuffer<> stehen bleibt.



Der Vorteil am "Externen" ist, dass man es für ALLE Klassen verwenden kann, ohne Diese erst anpassen zu müssen.



TMonitor hat den Vorteil, dass es multiplatform ist (CriticalSection ist ja Windows) und dass es angeblich schneller sein soll.
Aber der wirkliche Vorteil ist, dass man keine Variable dafür braucht. (OK, die braucht es immernoch, aber sie ist bereits in allen TObject-Nachfahren integriert)

[TurboMagic]

Zitat von himitsu:

Implizit ... joar, ich war schreibfaul ... statt du überall vor Ort zu machen,
kann man auch in der Ableitung die Methoden ala Add usw. überdecken/überschreiben und dort das Enter/Exit/Leave rein tun.

Überschreiben (virtual+override) ist besser, falls man zwar die TRingbuffer_Safe<> verwendet, aber die Variable auf TRingbuffer<> stehen bleibt.

Der Vorteil am "Externen" ist, dass man es für ALLE Klassen verwenden kann, ohne Diese erst anpassen zu müssen.

TMonitor hat den Vorteil, dass es multiplatform ist (CriticalSection ist ja Windows) und dass es angeblich schneller sein soll.
Aber der wirkliche Vorteil ist, dass man keine Variable dafür braucht. (OK, die braucht es immernoch, aber sie ist bereits in allen TObject-Nachfahren integriert)

Die Frage ist, was besser ist: meine Idee das schon als Konzept in die Basisklasse einzubauen diese Methoden aber leer
zu lassen (ist der Compiler schlau genug das bei Nutzung der Basisklasse als "nop" zu erkennen und somit auszulassen?)
oder alle public Methoden als Virtual zu deklarieren und in der abgeleiteten Klasse zu überschreiben? Wie sieht es mit
dem XMLDOC aus? Muss man den in der abgeleiteten Klasse duplizieren damit er funktioniert?

Grüße
TurboMagic

[Rollo62]

Zitat von himitsu:

TMonitor hat den Vorteil, dass es multiplatform ist (CriticalSection ist ja Windows) und dass es angeblich schneller sein soll.

<OT>
Schneller, einfacher: OK, aber wieso sollte TCriticalSection nicht multiplattform sein ?
https://docwiki.embarcadero.com/Libr...riticalSection

Für asymmetrische Pushs/Pops Szenarios böte sich da auch noch TLightweightMREW an.

</OT>

[Uwe Raabe]

Zitat von Rollo62:

Für asymmetrische Pushs/Pops Szenarios böte sich da auch noch TLightweightMREW an.

Push und Pop sind aber immer schreibende Zugriffe. Insofern sehe ich jetzt noch nicht den Vorteil eines MREW.

[Rollo62]

Zitat von Uwe Raabe:

Zitat von Rollo62:

Für asymmetrische Pushs/Pops Szenarios böte sich da auch noch TLightweightMREW an.

Push und Pop sind aber immer schreibende Zugriffe. Insofern sehe ich jetzt noch nicht den Vorteil eines MREW.

Stimmt auch wieder, ist ja ein Ring und der muss immer irgendwie geschrieben werden.
Allerdings könnten einige Abfrage-Funktionen womöglich mit InterlockedFunktionen abgesichert werden,
statt mit dem großen TMonitor Aufwand.

Meine aktuelle RingBuffer-Implementierung ist auf der Basis eines TMemoryStreams gemacht
weil es dabei um Byte-Ströme geht, mit CriticalSections, damit bin ich eigentlich ganz zufrieden.
Da nutze ich InterLocked Variablen als Indexzeiger, um unnötige Locks zu Vermeiden.
Ich wollte immer mal checken ob es schnellere, bessere Alternativen gibt.
Der RingBuffer mit ThreadWrapper könnte sowas sein, werde ich mal für mich austesten.

Dein Vorschlag mit dem universellen TThreadWrapper<T: class> = class macht schon viel Sinn,
weil man es dann auch auf viele andere Probleme übertragen kann.

Ich dachte bei dem RingBuffer ursprünglich dass es eine sehr Basic-Library oder Collection ist,
welche ihre eigentliche Aufgabe aus meiner Sicht möglichst komplett eigenständig abdecken sollte.
Das bezog sich aber sehr auf meinen speziellen Anwendungsfall, wo ich Pop/Push möglichst ohne Zusatzaufwand sicher entkoppeln möchte.

Durch den Wrapper wäre die Funktionalität und ThreadSicherheit aber auch schön sauber getrennt, und das passt dann noch in zig andere Situationen rein.
Und ja, Push/Pop/Peek, etc. sorgen dafür dass es doch nicht so einfach intrinsisch threadsicher werden kann,
ich benutze es momentan so, dass wenn was Neues drin ist, dann Lese und Bearbeite es.
Ein Peek nutze ich momentan nicht.
Das Duo mit dem Wrapper gefällt mir immer besser, wenn ich mal tiefer drüber nachdenke.

[TurboMagic]

Dann speise es nach deinen Tests bitte bei dem Projekt ein...
...damit auch die Allgemeinheit davon profitiert.

Grüße
TurboMagic