I shall refer to a higher authority:

> A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause.

That is from Modern Operating Systems, 4th ed. (2015), by A.S. Tanenbaum & H. Bos, page 439. (By "process" they really mean "process or thread".)

One way for thread A to wait on thread B is as you said: thread A can request a lock that thread B currently owns; then A waits for B. So requesting locks in opposite orders can result in deadlock. But of course if there are no locks, then no such waiting occurs, and so deadlock from this cause is impossible.

But there are other ways to wait. If var_a and var_b are shared variables, then code like the following might result in deadlock (The following code is in C; to simplify things, I'm assuming that data races and memory-access ordering are not issues.)

Thread A does:

    var_a = 1;
    while (var_b != 0) ;
    var_a = 0;

And thread B does:

    var_b = 1;
    while (var_a != 0) ;
    var_b = 0;

If Pony is capable of executing code like the above, then deadlock is possible.

Pony prevents you from writing that code. All communication between actors is by message passing, and there are no global variables. Check out reference capabilities.

You can deadlock in purely message passing code, even if there are no blocking sends. See an example in Erlang: http://james-iry.blogspot.com/2009/04/erlang-style-actors-ar...

That anti-pattern isn't possible in Pony, because Pony has no blocking receive call.

Of course, and Pony prevents programmer from writing code that waits for anything else. Sure. We're supposed to believe this?

Wow, so maybe the no-deadlock guarantee really does say something nontrivial. Thanks for the heads up.

There are many ways code can grind and thrash to a halt, like your code shows. But a deadlock refers specifically to the idea of two processes waiting until the other is done before they proceed. It's a scheduling problem, and a lock is used for synchronization. If there are no locks (spinlocks, semaphores, etc), there are no deadlocks by name (just other problems).

> ... there are no deadlocks by name (just other problems).

Okay, supposing we have a definition of deadlock that agrees with your usage: sure. But then these "other problems" you mention will have exactly the same practical effect as deadlock, right? A program will hang, sometimes unpredictably, based on more or less random decisions made by some low-level scheduling algorithm.

And in that case, Pony's guarantee of no deadlock is (1) completely correct, and (2) completely meaningless, from the point of view of a programmer whose concern is that his code will behave as required.

Am I wrong? EDIT. Maybe: https://news.ycombinator.com/item?id=10903876