Statische Allokation, konstante Arbeit: Wie TigerBeetle Ausfälle vermeidet
Static Allocation, Constant Work
In diesem technischen Blogbeitrag geht es um zwei Muster aus dem TigerStyle-Leitfaden von TigerBeetle: statische Allokation und konstante Arbeit. Der Autor erklärt, wie man durch die Begrenzung der Anzahl von Objekten (z. B. Orders) und die Einführung eines neutralen Zustands Speicherfehler und Leistungsabfälle vermeiden kann. Er argumentiert, dass diese Ansätze Vorhersagbarkeit und Robustheit erhöhen, auch wenn sie weniger speichereffizient sind. Der Beitrag enthält Codebeispiele in Zig und verweist auf verwandte Themen wie Memory Safety und Objektpools.
Statische Allokation gibt dir Seelenfrieden: Das System kann zwar nicht starten, wenn nicht genug Speicher vorhanden ist, aber wenn es startet, kannst du sicher sein, dass es Überlastung elegant bewältigt und den Dienst weiterhin erbringt, während du eine leistungsfähigere Maschine bereitstellst.
- mrkeen
> TigerStyle: Der gesamte Speicher muss beim Start statisch alloziert werden. Nach der Initialisierung darf kein Speicher dynamisch alloziert (oder freigegeben und neu alloziert) werden. Dies vermeidet unvorhersehbares Verhalten, das die Leistung erheblich beeinträchtigen kann, und vermeidet Use-after-Free.
Vielleicht erfüllt das Vorhalten eines Arrays von NULL-Aufträgen den Buchstaben des Gesetzes „keine dynamische Allokation“, aber ich bin nicht überzeugt, dass es den Geist erfüllt.
Hast du nicht einfach einen Puffer aus NULL-Aufträgen geschrieben, den du dann an Aufrufer verleihst (d. h. „alloziierst“ und „neu alloziierst“)?
Ist der kampferprobte Allokator eines anderen zu langsam oder fehlerhaft, also schreibst du deinen eigenen als Teil der Implementierung der Geschäftslogik?
- markus0
Ich möchte mehr mit Systemen arbeiten, die stets solch strengen Einschränkungen und Stil-/Designrichtlinien folgen, aber gleichzeitig habe ich das Gefühl, dass die Realität der Softwareentwicklung in großem Maßstab darin besteht, dass Teams in Subsystemen arbeiten, die das ganzheitliche Betriebsmodell des Programms nicht berücksichtigen. Selbst mit Best Practices auf lokaler Ebene endet das System als Ganzes fragmentiert und ineffizient, und strenge globale Einschränkungen wirken daher limitierend.
- pjmlp
Interessant, wie alle nach all den Jahren ständig die Programmiertechniken von 8- und 16-Bit-Heimcomputern wiederentdecken, was ich vermutlich größtenteils auf die Skriptsprachen für alles in den letzten zwei Jahrzehnten zurückführe.