https://www.hillelwayne.com/tags/tla+/ Recent content in TLA+ on Hillel Wayne Hugo -- gohugo.io en-us Mon, 17 Jun 2024 00:00:00 +0000 https://www.hillelwayne.com/post/composing-tla/ Mon, 17 Jun 2024 00:00:00 +0000 https://www.hillelwayne.com/post/composing-tla/ Last year a client asked me to solve a problem: they wanted to be able to compose two large TLA+ specs as part of a larger system. Normally you’re not supposed to do this and instead write one large spec with both systems hardcoded in, but these specs were enormous and had many internal invariants of their own. They needed a way to develop the two specs independently and then integrate them with minimal overhead. https://www.hillelwayne.com/post/graphing-tla/ Mon, 17 Apr 2023 00:00:00 +0000 https://www.hillelwayne.com/post/graphing-tla/ I haven’t written much about TLA+ on the blog since the new learntla went up. Any examples or special topics I think of go there instead. But I recently thought of a cool demo that doesn’t quite fit the theme of that book: there are some things you can’t easily check with the model checker but can check if you work with the state space as a directed graph. https://www.hillelwayne.com/post/learntla/ Fri, 01 Jul 2022 00:00:00 +0000 https://www.hillelwayne.com/post/learntla/ tl;dr: online TLA+ manual/advanced techniques/examples here. TLA+ is a tool for testing abstract software designs. I first stumbled on it in 2016 and found it so useful I wrote a free online guide to help others learn it. Then I decided the guide wasn’t good enough and wrote Practical TLA+ in 2018. Then I decided the book wasn’t good enough and needed a second edition. Just kidding! Book’s never getting a second edition, because it costs $26 and no matter how good I make it, it’s never going to have the reach of a free resource. https://www.hillelwayne.com/post/tla-adt/ Mon, 13 Dec 2021 00:00:00 +0000 https://www.hillelwayne.com/post/tla-adt/ In my 2021 TLAConf Talk I introduced a technique for encoding abstract data types (ADTs). For accessibility I’m reproducing it here. This post is aimed at intermediate-level TLA+ users who already understand action properties and the general concept of refinement. Say we want to add a LIFO stack to a specification. You can push to and pop from the end of this stack but you cannot change data in the middle. https://www.hillelwayne.com/post/refinement/ Tue, 13 Jul 2021 00:00:00 +0000 https://www.hillelwayne.com/post/refinement/ When teaching formal methods, I often get asked how we can connect the specifications we write to the code we produce. One way we do this is with refinement. All examples are in TLA+.1 Imagine we’re designing a multithreaded counter. We don’t know how we’re going to implement it yet, so we start by specifying the abstract behavior.2 ---- MODULE abstract ---- EXTENDS Integers, Sequences VARIABLES pc, counter vars == <<pc, counter>> \* Two threads Threads == 1. https://www.hillelwayne.com/post/action-properties/ Thu, 25 Feb 2021 00:00:00 +0000 https://www.hillelwayne.com/post/action-properties/ There’s not a whole lot on TLA+ technique out there: all the resources are either introductions or case studies. Good for people starting out, bad for people past that. I think we need to write more intermediate-level stuff, what Ben Kuhn calls Blub studies. Here’s an attempt at that. Most TLA+ properties are invariants, properties that must be true for every state in the behavior. If we have a simple counter: https://www.hillelwayne.com/post/tla-golang/ Fri, 25 Sep 2020 00:00:00 +0000 https://www.hillelwayne.com/post/tla-golang/ My job these days is teaching TLA+ and formal methods: specifying designs to find bugs in them. But just knowing the syntax isn’t enough to write specs, and it helps to have examples to draw from. I recently read Chris Siebenmann’s Even in Go, concurrency is still not easy and thought it would make a good case study for writing a spec. In it, he gives an example of Go code which deadlocks: https://www.hillelwayne.com/post/fairness/ Fri, 03 Jul 2020 00:00:00 +0000 https://www.hillelwayne.com/post/fairness/ I’m in the process of revising some of my workshops. I realized that one particular important aspect of TLA+, fairness, is something that I’ve struggled to explain well. Then again, everybody struggles to explain it well! It’s also a great example of how messy concurrent systems can get, so I figured it would make a good post for the blog. Stuttering Take the following spec of a clock. I used TLA+ but it should mostly be clear from context: https://www.hillelwayne.com/post/feature-interaction/ Wed, 05 Feb 2020 00:00:00 +0000 https://www.hillelwayne.com/post/feature-interaction/ In most testing frameworks, you’re expected to write a lot of low-level tests and few high-level tests. The reasoning is that end-to-end tests are slow and expensive and only cover a tiny amount of the program’s state space. It’s better to focus on testing all the parts in isolation versus testing that they all work together. In practice, global correctness does not follow from local correctness. It’s possible for every part to be individually rock-solid but the system to be broken as a whole. https://www.hillelwayne.com/post/business-case-formal-methods/ Wed, 22 Jan 2020 00:00:00 +0000 https://www.hillelwayne.com/post/business-case-formal-methods/ This is an “intro packet” you can use to argue for the benefits of formal methods (FM) to your boss. It’s a short explanation, a list of benefits and case studies, and a demo. Everything’s in TLA+, but the arguments apply equally well to Alloy, B, statecharts, etc. Adapt the material to your specific needs. Quick notational note: I’m leaving out the code verification side of formal methods, mostly because design verification is a much easier sell. https://www.hillelwayne.com/post/hyperproperties/ Mon, 13 Jan 2020 00:00:00 +0000 https://www.hillelwayne.com/post/hyperproperties/ When we design programs, we usually look for two kinds of properties: that “bad things” never happen and that “good things” are guaranteed to happen. These are called safety and liveness properties, respectively. These are properties that we want to hold true for every possible program behavior. “We always complete every request” is a liveness property. If our system has it, every program trace will complete every request. If it doesn’t hold, I can give you a example behavior where the server never responds. https://www.hillelwayne.com/post/adversaries/ Sun, 05 May 2019 00:00:00 +0000 https://www.hillelwayne.com/post/adversaries/ A common question I get about specs is how to model bad actors. Usually this is one of two contexts: The spec involves several interacting agents sharing a protocol, but some of the nodes are faulty or malicious: they will intentionally try to subvert the system. The spec involves an agent subject to outside forces, like someone can throw a rock at your sensor. These “open world” situations are a great place to use formal methods. https://www.hillelwayne.com/post/tla-messages/ Wed, 31 Oct 2018 00:00:00 +0000 https://www.hillelwayne.com/post/tla-messages/ I recently did a corporate TLA+ workshop and some people asked what TLA+ specs look like in practice. If you looked at the most common public examples, you’d probably come away thinking that people only used it for critical consensus algorithms. This is a problem for two reasons: first, it makes it harder to learn TLA+, as there aren’t simpler examples to experiment with. Second, it makes it hard for people to see how TLA+ is useful for them. https://www.hillelwayne.com/post/practical-tla/ Thu, 18 Oct 2018 00:00:00 +0000 https://www.hillelwayne.com/post/practical-tla/ I am delighted to announce that my book, Practical TLA+, is now available! When I stumbled into TLA+ in 2016 I had no idea it would so define my passions, my values, and my career. I definitely didn’t think I’d be writing a book. But 11 months and 220 pages later, here we are! This is the largest project I’ve ever done and I’m incredibly excited to share it with you all. https://www.hillelwayne.com/post/augmenting-agile/ Mon, 30 Jul 2018 00:00:00 +0000 https://www.hillelwayne.com/post/augmenting-agile/ I really like the c2 wiki as a historical artifact: a lot of big names in Agile and Extreme Programming argued with each other there.1 One thing they did was the Extreme Programming Challenge, where people tried to test the limits of these approaches. They’d find edge problems (designing databases, remote teams, etc) and see if Agile/XP still worked in that context. In almost every case they quickly decided that yes, it works just fine. https://www.hillelwayne.com/post/list-of-tla-examples/ Thu, 08 Mar 2018 00:00:00 +0000 https://www.hillelwayne.com/post/list-of-tla-examples/ People always tell me that the hardest part of learning TLA+ is finding good examples. This makes sense to me: most of the main ones out there are either toy problems or immensely complex algorithms. It’s sort of the nature of TLA+: if you’re using it, you’re trying to design something complicated, and that’s usually because you’re trying to sell something complicated. Also, the community is tiny. You could probably fit all of the TLA+ experts in the world in a small coffee shop. https://www.hillelwayne.com/post/tla-redux/ Mon, 12 Feb 2018 00:00:00 +0000 https://www.hillelwayne.com/post/tla-redux/ Update 01/07/19 Greetings from 2019! The good news is that Chicago isn’t yet a radioactive crater. The bad news is almost everything I said about refinement in this article is wrong. I’m working on writing a more in-depth, rigorous treatment of refinement as its own article. But this one is currently explaining something that definitely isn’t refinement. mkay thanks! Update 2020-10-05: I’m probably not going to write that article on refinement in the near future and also Chicago is a radioactive crater. https://www.hillelwayne.com/post/teaching-leaky-abstractions/ Tue, 30 Jan 2018 00:00:00 +0000 https://www.hillelwayne.com/post/teaching-leaky-abstractions/ I’m writing a book on TLA+! It’s going to be aimed at the same audience as Learn TLA+, but dive much deeper and go much further. I’ll be showing not just how to use TLA+, but how to think about systems, write good specifications, and fix models. I’m really excited and I’m sure you’ll be, too! I’m also trying to make it much better than Learn TLA+, because People are going to be paying money for this, so I can’t just phone it in I asked my technical reviewer to be “almost-comically brutal” and he’s risen to the challenge. https://www.hillelwayne.com/post/modeling-deployments/ Tue, 30 May 2017 11:48:17 -0500 https://www.hillelwayne.com/post/modeling-deployments/ I’m working on some examples for my TLA+ guide and realized this one would be a good introduction to specification in general, so I simplified it a little to make it more accessible. Enjoy! The problem Deploying code to a set of servers is tricky. You can turn them off, migrate the code, and turn them back on, but that’ll piss off the customers. You could also update them live, but different servers update are different rates and customers could get inconsistent results. https://www.hillelwayne.com/hate-your-tools/ Tue, 27 Dec 2016 19:48:18 -0600 https://www.hillelwayne.com/hate-your-tools/