Wed, Feb 27, 2019
FreeBSD Manual Page
There’s Giant lock, which is a special mutex used to protect data structures that do not yet have their own locks.
FreeBSD is written to run across many CPUs and provides different synchronization primitives to allow developers to safely access and manipulate many data types.
witness keeps track of the locks acquired and released by each thread. It also keeps track of the order in which locks are acquired relative to each other.
Standard mutex depends on kernel facilities which we’re implementing.
Sc. Standard locking would then not handle that. Locking would have, ordering locks have some locks better than others for performance.
Release all the locks in the worng order and acquire them. You have global lock and a lock per process. System call has process rather than ptable lock. Release own lock and acquire the ptable lock.
Witness code checks various other conditions, verifying one that does not recurse on non-recursive lock, or an upgrade on a shared lock held by another thread.
Recursive lock allows for counting.
Mutexes fully support priority propagation.
It’s useful in deadlock. A deadlock involves multiple threads at the same time. You want to know where else the lock was held. Thread A and Thread B acquires the lock. They are able to distinquish the different states.
If the mutex cannot be acquired, the thread requesting it will wait.
Lock classes are statically assigned an index into the lock_classes array. When debugging code, we look up the lock class for a given lock object by indexing the array.
We could modify the irq state, the deconstructor could result in a cpu and a backtrace. No idea which lock was locked or unlocked. They did not use a deconstructor for assertions. x86 has fewer assertions in library code. They don’t have assertions with state objects
OS161 has lock names, which is different from Chickadee’s lock names. OS161 is the previous operating system.
LINUX doesn’t have names for lock, the symbol table is linked ot the kernel.
You can look at its name in the address. xV6 locks have a backtrace embedded in them. It creates the backtrace when you create the lock.
Assertions make locks bigger.
Ticketing system state is created. Is this lock owned by some CPU? It there a backlog for these locks? A magic number is being moved and you can check that this is an actual lock. Owner CPU. The process that created the lock and right now all the locks are created in the kernel. Hierarchies make it pretty hard to function. Those fields prevent recursion, It can check the owner CPU and process before relocking.
Simulate critical regions for which logs are using the most time. Kthreads allow you to know which locks are used the most. You can get some debugging information.
Read and write locks are very interesting because they allow us to access the same code. Write locks allow us to write if we are only holding the lock. Read and write might be useful in Chickadee. Torture test. Lockdepth has a dependency depth runs assertions, no cycles. No interrupt context or a lock with interrupt disabled.