@AristosQueue wrote:
To understand when synchronous is safe, you have to know clearly when it is unsafe.
In bilateral communication, synchronous implies risk of deadlock. No synchronous? No possibility of deadlock. You literally never have to worry, "Is this possibly going to cause a deadlock in some rare situation?" My goal with AF was to make a system where the issues that were hardest to explain, hardest to replicate in debugging, and hardest to fix when they did crop up were ruled out by design rather than by convention. So once you admit synchronous into the communications, you have to think about it.
agreed, and by the way, I blame you, personally, for being the most influential person in convincing(or brow beating) me into "thinking" asynchronously. Thanks! But seriously, it has made me a better developer by a mile.
I started with "bilateral communication". Alice sends Bob messages; Bob sends Alice messages. As long as neither one waits for a response, no chance for deadlock. Deadlock occurs when Alice is waiting for Bob and Bob is waiting for Alice and neither one is checking their inbox to respond to the other. JDPowell notes that in a non-AF library, caller can synchronously query nested, but nested cannot query caller. That single-sided communication means no deadlock. Great.
by pure luck/intuition, I have always implemented one-way synchronous calls since joining the asynchronous church.
But there's a second trap in synchronous communication that you have to worry about: latency.
- Alice sends to Bob and waits for a reply
- Bob sends to Alice. Sends to Alice. Sends more to Alice. Finally gets around to checking inbox and replies to Alice.
- Repeat.
In this scenario, Alice's inbox is potentially filling up. Now you have definite hit of buffering or lossy messages, and you may have a bigger problem if Alice cannot clear inbox quickly between requests to Bob. And it gets worse if Alice is receiving messages from lots of senders.
I am usually way over cautious in situations where message traffic/throughput will be high, so thankfully haven't had to learn the hard way.
The more I researched massively parallel processing, the more I found that the number one thing to keep the software healthy was for every actor to be checking and clearing inbox as fast as possible. As long as we can generally assume "message sent is message received", our programs are much healthier.
So where are synchronous messages safe? On one side of a low-bandwidth connection. Or one side of a high-bandwidth connection where backlog of messages can be cleared out.
exactly what I was asking about. I mean, when I quick drop a math operator down on the BD, I am not worried at all about my program having to wait for it to return the result. I don't try to make some absurd non-blocking mechanism to perform addition because I know it will return in a fraction of a blink of an eye, and certainly faster than sending a message to another actor who's sole job is to perform addition.
People sometimes point out to me that it is safe to have sync messages on both sides of a connection where there's a timeout on the synchronous message. That breaks the deadlock at the cost of introducing a new failure mode. My problem with that idea is that handling the timeout case usually looks identical to async messaging -- if you make the timeout "0", it's pretty obvious that this is the same as asynch, so "synch with timeout" is generally just a performance enhancement on aysnch, not a replacement for asynch. At least, that's my experience.
I've also seen people try to get clever with synchronous comms using a DVR so that Alice can just query some value from Bob and get the latest that Bob has without waiting for an update message to come through the usual inbox from Bob to Alice. This way lies the madness of ill-defined state transmissions. It works at small scales, but it doesn't scale up at all. Messages arriving out of order and out of context is something code can deal with, but it's not trivial code for humans to write. There's a reason the world prefers TCP over UDP.
that's funny, I am pretty sure the DVR idea has crossed my mind in the past once or twice (and quickly recognized as a cheap way out and likely a bad idea).
There's lots of times you can safely introduce synchronous comms. But having done so, your second introduction carries increased risk to the system as a whole, and that risk increases over time. A well-defined rule like "callers to nested only" constrains that risk considerably.
