Ringpuffer Bibliothek veröffentlicht

[TurboMagic]

Hallo,

die Idee ist glaube ich gar nicht so schlecht!
Wenn die anderen diese auch als sinnvoll ansehen muss die nur noch jemand
offiziell einspeisen... ;-)

Am besten mit den Unit Tests die man, trotz der Schwierigkeiten Multithreaded
Code Unit getestet zu bekommen, umsetzen kann gleich beigesteuert. Am besten in
einer neuen Unit Test Klasse/Fixture...

Grüße
TurboMagic

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1499982)

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]

Ich habe das nochmal etwas verallgemeinert, da der Wrapper ja gar nichts über die zu wrappende Instanz wissen muss. Damit kann das als Wrapper für quasi jede Objekt-Instanz herhalten und man bekommt über LockInstance auch gleich den tatsachlich übergebenen Typ zurück mit allen dort verfügbaren Methoden und Eigenschaften.

Delphi-Quellcode:

type
  TThreadWrapper<T: class> = class
  private
    FLock: TObject;
    FInstance: T;
    FOwnsInstance: Boolean;
  public
    constructor Create(AInstance: T; AOwnsInstance: Boolean = True);
    destructor Destroy; override;
    function LockInstance: T;
    procedure UnlockInstance; inline;
    property OwnsInstance: Boolean read FOwnsInstance write FOwnsInstance;
  end;

...

constructor TThreadWrapper<T>.Create(AInstance: T; AOwnsInstance: Boolean = True);
begin
  inherited Create;
  FInstance := AInstance;
  FLock := TObject.Create();
  FOwnsInstance := AOwnsInstance;
end;

destructor TThreadWrapper<T>.Destroy;
begin
  LockInstance;
  try
    if OwnsInstance then
      FInstance.Free;
    FInstance := nil;
    inherited Destroy;
  finally
    UnlockInstance;
    FLock.Free;
  end;
end;

function TThreadWrapper<T>.LockInstance: T;
begin
  TMonitor.Enter(FLock);
  Result := FInstance;
end;

procedure TThreadWrapper<T>.UnlockInstance;
begin
  TMonitor.Exit(FLock);
end;

[himitsu]

Jupp, einige Methoden/Property kann man nicht Thread-safe machen.

Außer man lässt solch problematischen Methoden weg. Und falls man sie dennoch benötigt, dann in einer SubKlasse (ala LockBuffer) verstecken,
oder in diesen Methoden/Property eine Exception werfen, wenn vorher extern kein Enter/Lock gestartet wurde.

Die komplette Klasse muß man da nicht wegsperren, um die einachen Sachen weiterhin einfach/direkt aufrufen zu können.



Wenn FInstance immer keine Klasse ist, dann kannst statt FLock auch direkt FInstance verwenden, oder den TThreadWrapper selbst.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1500006)

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:

Zitat von Uwe Raabe (Beitrag 1500009)

Zitat:

Zitat von Rollo62 (Beitrag 1500006)

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

[Stevie]

Im Idealfall sollte ein thread-safer Ringbuffer lock-free sein und nicht einfach stumpf ne CS oder sowas nutzen.

[TurboMagic]

Zitat:

Zitat von Stevie (Beitrag 1500039)

Im Idealfall sollte ein thread-safer Ringbuffer lock-free sein und nicht einfach stumpf ne CS oder sowas nutzen.

Ich verstehe nur noch nicht ganz, wie man das umsetzen könnte?
Man muss ja meistens lesen bzw. schreiben und Start bzw. Ende Index aktualisieren.
Da das zwei verschiedene Operationen sind, könnte da ja immer jemand "dazwischen" grätschen...

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1500040)

Ich verstehe nur noch nicht ganz, wie man das umsetzen könnte?

Das ist ja eben das Problem bei lock-free Ansätzen... :)