Search code examples
concurrencyclojuredeadlockrace-conditionagent

Is it possible in Clojure to cause a deadlock (or another bad case) using agents?


Clojure agents are a powerful tool. Since actions to the agents are asynchronously sent using functions "send" and "send-off", in theory something like deadlock couldn't happen.

Is it possible to write some Clojure code (for example invoking from some action another action to another agent) using agents in which we have some concurrency problem - it could be deadlock, race condition or anything else.


Solution

  • send and send-off add the functions to queues for the agent and return immediately. Thus, due to their asynchronous nature, it is not possible for them to deadlock.

    However, the worker pool used by send is intended for computational work and is thus a fixed pool size (2 + # of cores). If you (incorrectly) invoke send with a task that can block for I/O or something else, that task will block one of the fixed number of cpu threads in the pool. If you did that with (2 + # of cores) tasks at the same time, you could effectively block the cpu thread pool. The solution of course is to use the correct send-off instead. The worker pool used by send-off is unbounded.

    On sending within an action, the agents page states:

    If during the function execution any other dispatches are made (directly or indirectly), they will be held until after the state of the Agent has been changed.

    When the dispatch occurs at the end of the agent, the send places the item in the send queue and returns immediately. Because agents never block waiting for a resource, there is no way to create a deadlock cycle.

    There is also no possibility for a data race - the state of an agent should be immutable Clojure data. The agent applies the change function within a send and replaces the state of the agent atomically. Readers (via dereference or @) see a stable value at some point in the agent's lifetime. If you need coordination of readers and writers, you must use refs.

    There is a possibility of a race condition: two calls to send from different threads can "race" to be put in the queue of an agent and also concurrent readers may perceive different (stable) values depending on when they read the agent's timeline. However, this is the nature of asynchronous computation. If you want coordinated computation when reading or writing multiple resources, you must use refs.