Actor model

First published:

Last Edited:

Number of edits:

The actor model is based on some abstract, mathematical design principles, focusing on having a framework to model and implement concurrency.

The general idea is relatively easy to understand: actors are a single unit of code-execution. In themselves there is no concurrency, and hence no need to add locks or any other protection.

Actors communicate with each other passing messages, which pile up in a queue. Actors can create other actors, and pass messages back and forth.

I believe the message passing interface may be an implementation of one of the crucial layers for the actor model. While reading the Wikipedia article, some things were reminiscent of what I tried to achieve using ZMQ, but without being so strict regarding what an actor was.

The PyKKA implementation of the actor model for Python is interesting, but it's focused on Threading for its async execution. That heavily limits the ability to improve performance, and hence it becomes an intermediate between Async and pure threads.

I am wondering the relationship of the actor model with instrumentation software. I wonder if the same principles can be applied when modeling the interaction between instruments.


Share your thoughts on this note
Aquiles Carattino
Aquiles Carattino
This note you are reading is part of my digital garden. Follow the links to learn more, and remember that these notes evolve over time. After all, this website is not a blog.
© 2021 Aquiles Carattino
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Privacy Policy