ck VS C++ Actor Framework

Maybe I'm missing something, but x is not volatile and the compiler is free to assume that it is not modified concurrently outside the bounds of C's memory model. Compilers can and do hoist out loop invariants, and https://github.com/concurrencykit/ck/commit/b54ae5c4ace9b94442bbb46858449069f566d269 seems like an example of compilers doing what you say they don't. What am I missing?

Recommend checking out http://concurrencykit.org instead.

If you're interested in how other approaches work, or how one achieves concurrency on shared mutable state without mutual exclusion, would recommend checking out concurrency kit.

There are plenty of practical solutions to the safe memory reclamation problem in C. The language just doesn't force one on you.

From epoch-based reclamation (https://github.com/concurrencykit/ck/blob/master/include/ck_..., especially with the multiplexing extension to Fraser's classic scheme), to quiescence schemes (https://liburcu.org/), or hazard pointers (https://github.com/facebook/folly/blob/master/folly/synchron..., or https://pvk.ca/Blog/2020/07/07/flatter-wait-free-hazard-poin...)... or even simple using a type-stable (https://www.usenix.org/legacy/publications/library/proceedin...) memory allocator.

In my experience, it's easier to write code that is resilient to hiccups in C than in Java. Solving SMR with GC only offers something close to lock-freedom when you can guarantee global GC pauses are short enough... and common techniques to bound pauses, like explicitly managed freelists land you back in the same problem space as C.

ck - Concurrency primitives, safe memory reclamation mechanisms and non-blocking data structures. BSD-2-Clause

Indeed they do, https://github.com/concurrencykit/ck

CAF

I'd like to mention the native actor model implementation CAF, the C++ Actor Framework, and share some experiences. (Disclaimer: I've been developing on CAF in the past and have a good relationship with the creator.) CAF (1) provides native actors without an VM layer, (2) type-safe interfaces so that the compiler yells at you when a receiver cannot handle a message, and (3) transparent copy-on-write messaging so that you can still push stuff through pipelines and induce only copies only when a ref count is greater than one.

In our telemetry engine VAST, we've been using CAF successfully for several years for building a distributed system that always has a saturated write path. CAF provides a credit-based streaming abstraction as well, so that you can have backpressure across a chain of actors, making burst-induced OOM issues a blast from the past. You also get all the other benefits of actors, like linking and monitoring, to achieve well-defined failure semantics: either be up and running or collectively fail, but still allowing for local recovery—except for segfaults, this is where "native" has a disadvantage over VM-based actor models.

With CAF's network transparent runtime, a message ender doesn't need to know where receiver lives; the runtime either passes the message as COW pointer to the receiver or serializes it transparently. Other actor model runtimes support that as well, but I'm mentioning it because our experience showed that this is great value: we can can slice and dice our actors based on the deployment target, e.g., execute the application in one single process (e.g., for a beefy box) or wrap actors into single OS processes (e.g., when deploying on container auto-scalers).

The deep integration with the C++ type system allowed us to define very stable RPC-like interfaces. We're currently designing a pub/sub layer as alternate access path, because users are interested in tapping into streaming feeds selectively. This is not easy, because request-response and pub/sub are two ends of a spectrum, but it turns out we can support nicely with CAF.

Resources:

- CAF: https://github.com/actor-framework/actor-framework

- VAST: https://tenzir.github.io/vast/docs/understand-vast/actor-mod... (sorry for the incompleteness, we're in migration mode from the old docs, but this page is summarizing the benefits of CAF for us best)

- Good general actor model background: http://dist-prog-book.com/chapter/3/message-passing.html#why...

VAST is a flight recorder and security content execution engine. On the one hand, there exists a continuous stream of high-volume data sources (such as network telemetry as NetFlow, Zeek, Suricata, and endpoint telemetry). On the other hand, VAST processes needle-in-haystack queries to provide answers to questions like "has this threat been relevant to us 8 months ago?", and supports threat hunters with an interactive query capability to explore the data. From an engineering perspective, we focus especially on the separation of read and write path, concurrent message passing in an actor model runtime (CAF), and leveraging open standards, like Apache Arrow, to establish a high-bandwidth data plane for sharing data with downstream tooling. A flexible plugin API enables additional security-specific use cases on top, such as realtime matching of threat intelligence or mining of asset data for passive inventorization.

Technologies: Apache Arrow, Flatbuffers, C++ Actor Framework, Linux, Docker, Kubernetes