Can functional programming languages have deadlock conditions?

Question

I am reading through "Clean Architecture: A Craftsman's Guide to Software Structure and Design" and it says that:

All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables.

Functional programming languages do not allow variables to be mutable. I can see why race conditions and concurrent update problems require the existence of mutable variables. However, I don't see how deadlock conditions require mutable variables.

Can someone help me address my knowledge gap? Or is the author of the book incorrect in his statement about deadlock conditions?

• Steve: "Functional programming languages do not allow variables to be mutable." - I think you'll find that, ultimately, the only data that is useful, is mutable. Functional languages do allow variables and other data to be mutable - there was just a lot of hype a few years ago about how the supposed answer to everything was immutability.
• Simon B: It's quite possible to write a program that deadlocks itself without mutable variables. Depending on your locking mechanism, lock(a); lock(a); may be sufficient for a thread to deadlock itself.

Answer 1

The quote is correct in principle. If you don't have any mutable state or side effects then you don't need to lock anything and without locks you don't get deadlocks.

But in reality, most programs, functional or otherwise, do need to operate with mutable state or side effects. Functional languages might not have mutable variables, but they might still need to interact with databases or files or IO resources, which is where locks may become necessary