https://www.hillelwayne.com/tags/blub-studies/ Recent content in Blub Studies on Hillel Wayne Hugo -- gohugo.io en-us Mon, 13 Dec 2021 00:00:00 +0000 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/decision-table-patterns/ Wed, 09 Sep 2020 00:00:00 +0000 https://www.hillelwayne.com/post/decision-table-patterns/ Decision tables are easy, simple, and powerful. You can teach them in five minutes and write one in half that time. You can look at a table and understand what it’s saying, see if it matches your problem, and check for design flaws. So it’s kinda weird that there’s basically nothing about them online. I wrote an introduction a while back, but I want something a little more formal. So this post will reintroduce the core ideas in a more formal way and then talk about some of the techniques you can apply to make better tables. 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/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.