Re: False positives in deadlock detection

Gábor Melis <[email protected]>
Newsgroups gmane.lisp.steel-bank.general
Message-ID <CADJFn4Xe+xJ_72vbGz5=gg-1zJS7d4Cac7OnDwee7v4Np9NWzg@mail.gmail.com>
On Fri, 15 Mar 2024 at 14:53, Stas Boukarev <[email protected]> wrote:
> You don't need to stop the world because if there is a deadlock the threads are aleady stopped.

I haven't thought much about whether real deadlocks would get detected.
But deadlocks may be detected where there aren't any.

> Which part is racy?

I suspect it's racy because I couldn't convince myself otherwise in
half an hour. Here is my thinking.

While CHECK-DEADLOCK is running, other threads are acquiring and
releasing locks, leading to situations like in this report. The chain
can be completely bogus in that it does not correspond to a consistent
snapshot (that one could get with the world stopped). Even a single
step in the chain -- looking up the owner of a lock and then looking
up what the owner thread is waiting for -- can give us a lock-to-lock
edge in the graph that never existed, if between the two lookups the
owner thread releases the lock and proceeds to block on another.

If the read barriers somehow guarantee that this cannot happen, I
can't see it.

The recheck needs to do what the comment [1] says:

    ;; Recheck that the mutex is still owned by the same thread.

... while the code that follows seems happy if the mutex is owned
_again_ by the same thread, or if the change of ownership is not yet
visible to this thread.



[1]: https://github.com/sbcl/sbcl/blob/1aaeffe0bc7319f07413077a9a0c17877f995a4a/src/code/target-thread.lisp#L588C45-L588C102
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.