Contributed by weerd on from the fusing-locks dept.
Ted Unangst (tedu@) was the first developer to write in with his report from the hackathon in Toronto. Find his story below:
I spent most of the hackathon working on a few SMP and thread related issues. One problem is that over time we've accumulated lots of different kinds of locks, and some work and some don't, leading to confusion. The obvious solution then is to introduce a new kind of lock that you do understand.
Oh, wait, no; the solution is to delete the crap. No hackathon is complete until I've deleted a bunch of code from somewhere, so to get things started I deleted all the simple_locks from UVM. simple_locks have never been real locks on OpenBSD, but were retained optimistically hoping that one day we could just flip a switch and everything would magically be SMP safe. Over time the optimism faded to an attitude more like we should keep the locks around because they will serve as useful hints to whoever is going to add real mutexes to UVM. More time passes, more UVM code is changed, and the simple_lock remnants are no longer hints. They're lies! Fiery death ensues.
After that, I tried cleaning up the spinlock_lock_t type. This started as a project to convert librthread spinlocks to ticketlocks (a ticket lock is a more fair spinlock that guarantees everybody gets to run; one thread can't hog the lock). But now I had both struct spinlock and spinlock_lock_t types running around in the same program. See above about continued introduction of new types. In this case, the old locks were still useful (and in fact still used as the new locks' core), but the name was poor. The old spinlock_lock_t became atomic_lock_t and I simplified and unified the various machine dependent headers.
Unfortunately, I did so rather poorly and miod had to fix a few things on the platforms I didn't test on. In the end, the ticketlocks were mostly reverted, but in a way that makes moving forward again easier. The resulting breakage also revealed some other things that are more fragile than the should be. Eventually the goal is to allow us to experiment with different lock types and have some confidence that machine independent code tested on one platform will work on all platforms because each platform provides the right (and consistent) building blocks.
Then I spent some time looking at SMP and scheduler patches for the kernel. Various patches exist that never got committed because the timing wasn't right. Maybe it was near a release or maybe the right developers weren't interested at that time, and then the diff gets forgotten. Whatever the reason, I'd like to see stalled diffs start moving forward again.
Also in the category of somebody else did all the hard work, I checked in a newly written FUSE (userland filesystem) implementation by Sylvestre Gallon.
Thanks to Ted for this report, we hope to be back with more submissions soon!
(Comments are closed)