boc: Behavior-Oriented Concurrency for Python

Let's Get Cooking!

In this example, we are going to look at a program which simulates cooking an omelette:

# first declare our resources

onion = Ingredient("onion")
pepper = Ingredient("pepper")
eggs = Ingredient("egg", 3)
cheese = Ingredient("cheese")
knife = Utensil("knife")
whisk = Utensil("whisk")
grater = Utensil("grater")
pan = Cookware("pan")

# ...our recipe

omelette = Recipe("omelette", {
    "onion": "diced",
    "pepper": "chopped",
    "egg": "beaten",
    "cheese": "grated"
})

# ...then our steps

knife.dice(onion)
knife.chop(pepper)
whisk.beat(eggs)
grater.grate(cheese)
pan.cook(omelette, (onion, pepper,
                    eggs, cheese))

With only one cook, there is no problem. However, if we introduce a second cook into the kitchen, then we start having potential problems. In programming terms, if we make this single-threaded program concurrent, then the resources become shared, and we have to handle contention. After all, both cooks cannot use the knife at the same time! We also have to handle ordering of operations, to ensure the ingredients have been prepped before they are used. Let's reframe this program using this table below:

	Onion	Pepper	Eggs	Cheese	Knife	Whisk	Grater	Pan
Dice Onion
Chop Pepper
Beat Eggs
Grate cheese
Cook Omelette

Ideally, we want our cooks to work in parallel, so as to reduce time to breakfast, something like this:

Cook 1	Dice Onion	Grate Cheese
Cook 2	Beat Eggs	Chop Pepper	Cook Omelette

If we were to code this using traditional threads and locks, we may write it like this:

def cook1():
    with onion.lock:
        with knife.lock:
            knife.dice(onion)

    with cheese.lock:
        with grater.lock:
            grater.grate(cheese)


def wait_until_ready(ingredient: Ingredient,
                     state: str):
    with ingredient.lock:
        if ingredient.state == state:
            return

    with ingredient.condition:
        while ingredient.state != state:
            ingredient.condition.wait()

def cook2():
    with eggs.lock:
        with whisk.lock:
            whisk.beat(eggs)

    with pepper.lock:
        with knife.lock:
            knife.chop(pepper)

    wait_until_ready(onion, "diced")
    wait_until_ready(cheese, "grated")

    with onion.lock:
        with pepper.lock:
            with eggs.lock:
                with cheese.lock:
                    with pan.lock:
                        pan.cook(omelette,
                                 (onion,
                                  pepper,
                                  eggs,
                                  cheese))

There is a lot going on all of a sudden! First and foremost we see the need to explicitly split up tasks between worker threads. There are ways to do this automatically of course (e.g., producer/consumer queues) but for the sake of simplification we have divvied up the work optimally between the two cooks. Secondly, we have the need to acquire and release locks. This is fairly straightforward for cook 1, but because cook 2 has to cook the omelette they have the additional task of waiting until the other ingredients have been prepared by cook 1. This requires an additional Condition variable on each ingredient to allow cook 1 to be notified of changes to the ingredient's state. This example is presented in full working form on Github. It all works, but we believe there is a simpler and more intuitive way to code this program cowns and behaviors

cowns

A concurrent-owned variable (cown) ensures that only one thread of execution can access its contents at a time. In particular, this is enforced at the level of Python's GIL, meaning a cown can only be accessed by one interpreter at a time. However, the reference to a cown can be shared between multiple processes. Under the hood, cowns use Python's cross-interpreter data API to allow data to safely move across interpreter boundaries. Take the scenario below, for example, in which you have a cown that is referenced by two different interpreters.