4 ms·
Not once did I see the author mention “actors”, an entire generation of skilled engineers tries to reinvent them (with conflicting naming) poorly, this is a fai
by smallstepforman 3y ago
Not once did I see the author mention “actors”, an entire generation of skilled engineers tries to reinvent them (with conflicting naming) poorly, this is a failing of our industry’s academia and trade press.
Actors are asynchronous objects with a message queue, designed to run on a thread pool. You can pin them to a core, or allow migration via work stealing (to spread the workload). Did you know that in modern many core systems, a hot CPU core will halt to cool down? Work stealing will offload non-pinned actors, balancing the load.
There is one stumbling issue with Actors which is “sync” work, a transaction which requires one actor to update anothers state before continuing. This can be resolved by “locking” an actor, but this mechanism is consceptually “dirty”, but solves real world problems.
- jandrewrogers 3y ago> or allow migration via work stealing (to spread the workload) FWIW, work stealing is often not recommended in thread-per-core architectures because it introduces quite a bit of unnecessary thread contention. You are correct that load balancing is a central problem in these architectures but it is usually achieved by shedding data since that can be done with minimal locking and inter-thread coordination. This moves the problem to figuring out what data to shed but this has satisfactory inexpensive solutions in many system designs.
- u320 3y agoThe people who invented TPC were not unaware of the actor model. They just found it unsuitable for their needs.
- rat9988 3y agoI'm pretty surprised you think the author should have bothered talking about actors. Why ?
- yaantc 3y agoBecause the article is on developing a "shared nothing" system where sharing is replaced by communications. Actor systems are also about shared nothing and using messages based communications, and they came first historically. Now to be fair, a lot of actor systems were about correctness and not squeezing the most performance of a platform. Not sharing data means no explicit locking with mutexes (though one can still have deadlocks, as in several actors stuck waiting for each others) and something simpler to analyze: the system is made of communicating state machines. Actors were also used in high performance system like telecom switches (high performance, for their time), but here too correctness was probably the main concern. At the time actors were first used accessing even far memory was not as costly as today, so the cost of synchronization wasn't as bad. But it was already tricky to get right. Still, actors are perfectly on topic when discussing a shared nothing, message based architecture. They're worth mentioning IMHO, to give some historical perspective. And then one can combine both approaches: a pinned thread per core can dispatch its messages to a set of cooperating actors for example.
- rat9988 3y agoThread per architecture is a topic in and by itself in computer science. I feel like you are talking about it as if the author invented it to solve its needs.
- yaantc 3y agoOh I'm well aware the author didn't invent any of this: I'm currently working on a "VPP lite" [1] implementation for an embedded packet processing application and as part of my "SoTA" review learned about TPC history (in networking at least). I was just trying to answer your question on why agents could be relevant here, nothing more. [1] https://fd.io/docs/vpp/master https://fd.io/docs/vpp/master
- rat9988 3y agoThank you for your answer, and interesting repo by the way, hope your implementation of the lite version goes well :)
- deleted 3y ago[deleted]