The Deadlock Empire: An Interactive Guide to Locks
deadlockempire.github.io
The Deadlock Empire: An Interactive Guide to Locks
1–10 of 44 posts
Re: The Deadlock Empire: An Interactive Guide to Locks
#2My main takeaway from this excellent guide is that I suck at multithreaded reasoning and should stick to single threaded languages.
There go my dreams of being a C-slinging kernel ninja master.
Re: The Deadlock Empire: An Interactive Guide to Locks
#3Oh, that's just precious.
It stops before the problems of lock congestion, infinite overtaking, and priority inversion, though.
Re: The Deadlock Empire: An Interactive Guide to Locks
#4My main takeaway from this excellent guide is that I suck at multithreaded reasoning and should stick to single threaded languages. There go my dreams of being a C-slinging kernel ninja master.
It's not that bad. It's helpful to understand what's happening down at the instruction, memory access, and fence level, but most code just uses some kind of scoped mutex. You don't often have to think all this through.
The big win in Rust is that the mutexes are tied to the data they protect. The compiler won't let you access data until it's locked. You can still deadlock, though.
Re: The Deadlock Empire: An Interactive Guide to Locks
#5My main takeaway from this excellent guide is that I suck at multithreaded reasoning and should stick to single threaded languages. There go my dreams of being a C-slinging kernel ninja master.
You might find Curt Schimmel's UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers useful.
Re: The Deadlock Empire: An Interactive Guide to Locks
#6It's missing my favourite optimistic lock, the Delusional Lock.
Re: The Deadlock Empire: An Interactive Guide to Locks
#7My main takeaway from this excellent guide is that I suck at multithreaded reasoning and should stick to single threaded languages. There go my dreams of being a C-slinging kernel ninja master.
If it's any consolation: the vast, vast majority programmers should stick to single-threaded design, as is evident from all the atrocious multithreaded software out there of which 99% of the time would be faster without multiple threads (and surely far less complex)
Unless you know what you're doing, just pick the real low-hanging fruit, like throwing some threads at file block decompression.
Re: The Deadlock Empire: An Interactive Guide to Locks
#8My main takeaway from this excellent guide is that I suck at multithreaded reasoning and should stick to single threaded languages. There go my dreams of being a C-slinging kernel ninja master.
I'll give you one tip that covers a large portion of deadlocks I've seen in my career.
A lock should be used to lock a data structure, that's it. Corollary: Never hold a lock while calling a function.
Most common deadlocking scenario is people taking a lock, calling a function, that they don't know takes a different lock. If you can't get by just taking a lock, touching some data structure (lightly), and releasing the lock then you need to look at your data structures.
Re: The Deadlock Empire: An Interactive Guide to Locks
#9Oh, that's just precious. It stops before the problems of lock congestion, infinite overtaking, and priority inversion, though.
It also assumes all reads and writes are volatile. In the real world, threads can witness out-of-order execution in different threads.
Re: The Deadlock Empire: An Interactive Guide to Locks
#10It's missing my favourite optimistic lock, the Delusional Lock.
You can submit a feedback! https://docs.google.com/forms/d/e/1FAIpQLSf7XQBKbpjtOqzFi0jB...