[erlang-questions] a question about pragmatic deadlock solutions

[Fred Hebert]

On 07/09, Raoul Duke wrote:
> "Unfortunately, this problem [deadlock among actors] rarely comes up
> in simple designs or initial implementations. It is only as the code
> matures and the complexity increases that deadlocks begin to occur.
> Supervisors detect such failed actors and restart them, which in turn
> gives rise to the increased chance that messages will be lost. So
> timeouts are often added, further increasing the complexity of the
> code and potentially giving rise to an increasing frequency of
> deadlocks."
> 
> Do people see this in real world Erlang?
> 

Yes and no.

When designing a system, I try to avoid having processes requiring to
exchange information directly in a one-on-one manner. This should really
happen only in limited cases, when they represent peers with equal
decisioning power talking to each other, for example.

The most frequent pattern I encounter is often one of authority, where a
process gets to either lead progress, or where one asks for information
to another one. These have few chances of deadlocking there.

Peer-to-peer cases (a chat system, a trading system, etc.) can often be
transformed into an authoritative one by adding a third process that
will act as a mediator and will lead things (a chat room, a
marketplace). These will tend to move the information flow in a way that
has a clear leader or coordinator.

When they can't be, that's when fun begins, and yes, it's entirely
possible to get deadlock situations if you're not careful. The example
of a trading system FSM that can act peer-to-peer asynchronously is an
example of the complexity that arises there. The copy in the book still
has one of these in there (jlouis spotted it, but it happens so early in
the protocol that fixing it would have made everything even less
readable).

In practice, I've seen these situations light years ahead of when they'd
happen by just how frustrating design becomes. Defering to a third party
to lead the dance is often much, much simpler.

Regards,
Fred.