3 ms·

Hi Carl. Pleasure to read your comments. I’ve tried applying Actors to my C++ projects and always hit 2 issues in Actor model: 1) the need for synchronous acc

Hi Carl. Pleasure to read your comments. I’ve tried applying Actors to my C++ projects and always hit 2 issues in Actor model: 1) the need for synchronous access. As long as a single thread is accessing each Actor sequentially, then there is no issue with locking an Actor for synchronous access (barring deadlocks). I feel dirty locking Actors, but it solves many practical problems. 2) sharing resources requires a language which understands locks, since even Pony’s reference capabilities doesn’t solve real world performance issues. Ideally, each shared resource would have a paired lock whose usage the compiler verifies. Both issues deviate from Actor model purity since they require locks, but I cannot resolve real world performance problems without them.

ProfHewitt 7y ago
Thanks! Unfortunately, C++ has many issues implementing Actors because of problems with regions of mutual exclusion with holes. See the following: https://papers.ssrn.com/abstract=3418003 https://papers.ssrn.com/abstract=3418003
- DonHopkins 7y ago
  Hi, and thank you for all your intriguing messages and thoughtful arguments! I've heard that Actors don’t have an identity, only addresses: https://medium.com/@alex_karaberov/everything-you-always-wanted-to-know-about-the-actor-model-but-were-afraid-to-ask-b6eee8722953 https://medium.com/@alex_karaberov/everything-you-always-wan... >Each actor has an address. In various implementations an address can be a direct physical address (e.g. MAC address of the NIC), email, memory address, some id and so on. Multiple actors can have the same address, and one actor can have multiple addresses. There is a many-to-many relationship here. Address is not a unique identifier of the actor. Actors don’t have an identity, only addresses. So, when we step back and look at our conceptual Actor Model, we can see and use only addresses. We can not tell whether we have one actor or multiple ones even if we have one address, because it can be a proxy for the group of actors. All we can do with an address is send it a message. Address represents capability in the Actor Model. Mapping of addresses and actors is not part of the conceptual Actor Model although it is a feature of implementations. So I was wondering if you're the same Carl E Hewitt as https://news.ycombinator.com/user?id=carlehewitt https://news.ycombinator.com/user?id=carlehewitt and as your user name professes, or if either or both of you are actors? ;) And have you ever played Santa Claus? https://www.youtube.com/watch?v=AtnBumt82_Y https://www.youtube.com/watch?v=AtnBumt82_Y
  - ProfHewitt 7y ago
    Don, you are very welcome! Alexander Karaberov's article (linked above) is an important contribution. You are correct that since an Actor can have many addresses, it is not clear what it would mean for an Actor to have an identity." PS. Excellent SNL Santa :-)
- ProfHewitt 7y ago
  PS. If you employ locks correctly, you can do regions of mutual exclusion (with holes) in C++ :-)
Floegipoky 7y ago
I feel woefully inadequate among present company, but nonetheless offer my 2 cents: There is a fundamental performance tradeoff between sequential vs concurrent computation, because concurrency always requires some form of communication. Locks are difficult to reason about, but allow for shared resources. I've found the actor model to be so useful because it allows me to trade the ability to share resources for a more intuitive form of communication, message passing. Regarding your 1st point: Each actor is itself a sequential computer. You can't share an actor between threads any more than you could share a Turing Machine between threads. When designing actor systems I imagine a 1:1 mapping between threads and processors. The concurrency is happening in userspace. Regarding your 2nd point: It's my feeling that current actor model implementations are only suited to a narrow range of problems characterized by massive concurrency, a lack of shared state, and flexible time requirements. If any of those aspects are missing, I've learned to look elsewhere for a solution.

ProfHewitt 7y ago

Thanks! Unfortunately, C++ has many issues implementing Actors because of problems with regions of mutual exclusion with holes. See the following: https://papers.ssrn.com/abstract=3418003 https://papers.ssrn.com/abstract=3418003

DonHopkins 7y ago
Hi, and thank you for all your intriguing messages and thoughtful arguments! I've heard that Actors don’t have an identity, only addresses: https://medium.com/@alex_karaberov/everything-you-always-wanted-to-know-about-the-actor-model-but-were-afraid-to-ask-b6eee8722953 https://medium.com/@alex_karaberov/everything-you-always-wan... >Each actor has an address. In various implementations an address can be a direct physical address (e.g. MAC address of the NIC), email, memory address, some id and so on. Multiple actors can have the same address, and one actor can have multiple addresses. There is a many-to-many relationship here. Address is not a unique identifier of the actor. Actors don’t have an identity, only addresses. So, when we step back and look at our conceptual Actor Model, we can see and use only addresses. We can not tell whether we have one actor or multiple ones even if we have one address, because it can be a proxy for the group of actors. All we can do with an address is send it a message. Address represents capability in the Actor Model. Mapping of addresses and actors is not part of the conceptual Actor Model although it is a feature of implementations. So I was wondering if you're the same Carl E Hewitt as https://news.ycombinator.com/user?id=carlehewitt https://news.ycombinator.com/user?id=carlehewitt and as your user name professes, or if either or both of you are actors? ;) And have you ever played Santa Claus? https://www.youtube.com/watch?v=AtnBumt82_Y https://www.youtube.com/watch?v=AtnBumt82_Y
- ProfHewitt 7y ago
  Don, you are very welcome! Alexander Karaberov's article (linked above) is an important contribution. You are correct that since an Actor can have many addresses, it is not clear what it would mean for an Actor to have an identity." PS. Excellent SNL Santa :-)
ProfHewitt 7y ago
PS. If you employ locks correctly, you can do regions of mutual exclusion (with holes) in C++ :-)

Floegipoky 7y ago

I feel woefully inadequate among present company, but nonetheless offer my 2 cents: There is a fundamental performance tradeoff between sequential vs concurrent computation, because concurrency always requires some form of communication. Locks are difficult to reason about, but allow for shared resources. I've found the actor model to be so useful because it allows me to trade the ability to share resources for a more intuitive form of communication, message passing. Regarding your 1st point: Each actor is itself a sequential computer. You can't share an actor between threads any more than you could share a Turing Machine between threads. When designing actor systems I imagine a 1:1 mapping between threads and processors. The concurrency is happening in userspace. Regarding your 2nd point: It's my feeling that current actor model implementations are only suited to a narrow range of problems characterized by massive concurrency, a lack of shared state, and flexible time requirements. If any of those aspects are missing, I've learned to look elsewhere for a solution.