Prefer inheritance over composition.

Nah just kidding, it’s the opposite!

Prefer composition over inheritance.

Why Inheritance is Generally Bad

The reasons being that:

• Inheritance introduces sneaky (hidden) behavior.
• Understanding deep inheritance hierarchies are difficult.
• Restricts flexibility in terms of mixing and matching behaviors.

Let’s expand on these.

Hidden Behavior

When you are looking at the source code of a component (class in this case), and the component inherits, you are missing a bunch of hidden methods/fields. You are not looking at the full picture of the class’s data/behavior. There is a hidden repository of behavior, the base class.

This situation is exacerbated when the base class also has a base class and so on; in other words, when the inheritance hierarchy is deep.

You may think that a class is very small and cohesive when in actuality it is not.

Understanding Deep Inheritance Hierarchies are Difficult

Deep inheritance hierarhcies require you to jump around several files to understand a single class. Typically one file for each class in the inheritance chain. This makes understanding them more difficult and thus maintainance more difficult.

Restricts Flexibility

There are well known problems with multiple inheritance (diamond inheritance problem). So if you “inherit” behavior you can only inherit it via the inheritance chain, a class cannot (reliably) “inherit” multiple behaviors by inheriting from multiple base classes.

This restricts your ability to mix and match behaviors in a derived class (because it can only inherit from one base class - reliably).

Composition to the Rescue

Instead of inheriting data/behavior (fields/methods) from a base class, just use the base class through composition (delegate to it).

When you need to inherit just behavior (just methods), just make free functions, no need to inherit at all.

When you need to also inherit data, create an instance of the class and delegate to it.

This way, if you need to inherit data/behavior from multiple “base” classes, you just create each of them as an instance variable and delegate to them!

This makes all the methods of your class explicit (even though most of them will simply be pass through methods).

Speaking of which, you will get a lot of pass through methods when choosing composition over inheritance, but the idea is that these additional pass through methods are worth 1) making the behavior explicty (no hidden behaviors) and more importantly 2) allowing mix and match flexibility.

Proper Application of Inheritance

Like most things in software engineering (and in life) things are not black and white. Inheritance isn’t always bad, and there are times when it is the perfect tool.

If you have a short inheritance hierarchy (2-3 levels) it can save you a lot of pass through functions. It is well suited for situations like in a GUI frameworks where you have a base GuiElement-like class with a ton of basic functionality common to all GUI widgets.

Summary

• Yes, composition is generally better than inheritance.
• But inheritance isn’t always bad.
  • Keep your inheritance hierarchies short.

Have an awesome day!

Using With Cloud Run

Let’s assume you have a service running in Cloud Run. Internally a load balancer is used by Cloud Run to route traffic between different instances of your service.

graph LR;
    A[Client] -->|Request| B[Load Balancer];
    B -->|Routes to| C[Cloud Run Service Instance];

In the settings of your Cloud Run service, you can enable IAP. When you enable this, the load balancer will now authenticate incoming requests before routing them.

graph LR;
    A[Client] -->|Request| B[Load Balancer with IAP];
    B -->|Routes to| C[Cloud Run Service Instance];

If a request is unauthenticated, the load balancer (IAP) will respond with:

• If client is a browser: HTTP 302 redirecting the user to a Google sign-in page (which has query parameters to redirect back to the original URL after sign-in).
• If client is not a browser: HTTP 401 Unauthorized.

In the latter case (client is not a browser), client is expected to fill the Authorization header with a valid token.

You can generate a token by using the key associated with a service account that has the IAP-secured Web App User role (or another role with the iap.httpsResourceAccessor permission).

Using With Other Services

If you’re service is not running in Cloud Run, you can still enable IAP by placing your service behind google’s load balancer.

For example, if your service is running in a VM, you can enable a load balancer in front of it, and then enable IAP on that load balancer.

• IAP can be used to enable authentication for your GCP services (like Cloud Run, Compute Engine, etc) without having to modify your application code.
• If you are using Cloud Endpoints, enable auth there, you can’t use IAP (cloud endpoints API gateway has its own auth mechanism)

IAP is a quick and dirty way in GCP to add authentication to your services. For cloud run, just enable IAP in the console settings and it’ll be enabled in the load balancer. For other resources, first place them behind a GCP load balancer, and then enable IAP on that load balancer. For anything you want to grant access, just give the service account the IAP-secured Web App User role.

• What “proving possession” is and how to prove it. I.e. how do you know you are talking to who you think you are talking to?
  • What is a “challenge”?
• What “signing” is, how to sign something, and how to verify that someone specific signed something.
• What TLS is and how it works (including mutual TLS).
  • What a certificate authority (CA) is. How to verify certificates with a CA.
• What HTTPS is and how it works.

Public-Private Key Pair

Let’s start with an axiom: anything encrypted with a public key can only be decrypted with the corresponding private key, and vice versa. We won’t get into the math (because I don’t know it lmao).

Proving Possession

You (A) want to establish a communication channel with some entity B. How do you verify that it is really B that you are communicating with? You have B’s public key (you know who you want to communicate with), you issue “him” (person claiming to be B) a challenge, and he uses his private key to solve the challenge. Now you know it’s really B.

sequenceDiagram
    participant A
    participant B
   
    A->>B: Challenge
    B->>A: Response
    Note right of B: B used his private key to solve the challenge
    A->>A: Verify
    Note right of A: A verifies the challenge was correctly solved

Essentially, someone can prove they are B by knowing something only B would know (his private key). The challenge is to prove he has the private key.

Let’s dive in a little. There are two main ways to do this challenge. Let me explain via diagrams. Less words more diagrams :).

sequenceDiagram
    participant A
    participant B

    A->>B: Challenge
    Note right of B: A's challenge is a random string encrypted with B's public key
    B->>A: Response
    Note right of B: B decrypts it with his private key, returns the original random string
    A->>A: Verify
    Note right of A: A verifies he got back the same random string he sent

By the way, this whole thing is called “proving possession”. This is how you can prove that someone possesses the private key corresponding to a public key.

Here’s a second way to do a challenge.

sequenceDiagram
    participant A
    participant B

    A->>B: Challenge
    Note right of B: A generates a random string, Asks B to sign it with his private key
    B->>A: Response
    Note right of B: B signs the random string with his private key
    A->>A: Verify
    Note right of A: A decrypts the signature using B's public key, sees if original string is there

So, you start with a random string S, B encrypts (transforms) it with his private key into S’. You transform S’ using B’s public key and you get back S, thus possession is proven.

graph LR
    S -->|transform with B's private key| S'
    S' -->|transform with B's public key| S

Signing

When you want to sign a message, you create a hash of the message and then encrypt the hash with your private key. This (the encrypted hash) is called the signature of the message (it is included with the message).

When someone wants to verify that it was you (A) who signed it. They will take your public key and decrypt the signature. If the decrypted hash matches the hash of the message, then it was indeed you who signed it.

graph TD
    Hash -->|transform with private key| Signature
    Signature -->|transform with public key| Hash'
    Hash' --> C{Same as original hash?}
    C -->|yes| Verified
    C -->|no| NotVerified

Signing a message is done with a private key. Verification is done with a public key.

TLS

TLS is when you want to establish a secure communication channel over an insecure network.

Goes back to what we started with. If you are A and you want to talk to B. You need to verify that it is really B you are talking to (“proving possession” via a challenge).

Once you have verified B’s identity, you need to establish a secure communication channel. You do this by agreeing on a symmetric key (a key that both A and B know). This symmetric key is then used to encrypt all communication between A and B.

A symmetric key is a key that can be used to both encrypt and decrypt a message.

The actual technology of the channel can be anything, though often it is a TCP connection.

Certificates and Certificate Authorities

One caveat - in TLS, the server presents a “certificate” to the client. This certificate contains the server’s public key (as well as some “claims”/”roles”). This certificate is signed by a 3rd party, called a certificate authority (CA).

You 1) verify validity of the certificate (check if it’s signed by a trusted CA) 2) verify that server identity is who is stated on the cert (the public key stated in the cert). 1 is done by verifying the signature on the certificate presented (that it is the signiture of the CA). 2 is done by a challenge.

The purpose of the certificate is to bind the public key to certain things like the identity, permissions, and other attributes of the entity it represents.

Mutual TLS

In non mutual TLS, only one entity (generally called the “server”) is authenticated (proves identity, proves possession). In mutual TLS, both entities (the “client” and the “server”) authenticate each other.

You can imagine how this works. Both have certificates issues by a CA. Both exchange certificates with one another. Both verify the other’s certificate using the CA.

Verifying a certificate means checking that it was signed by a CA.

HTTPS

HTTPS is simply HTTP over a TLS (TCP) socket. That’s it! Short and sweet :).

This is the benefit of learning fundamentals well, higher level concepts barely add anything new!

A finite state machine (FSM) has a bunch of states that it can be in, and while in a certain state, it transitions to other states based on inputs (events/actions) received while in that state.

graph LR;
    State1 -->|input| State2;
    State2 -->|input| State3;
    State2 -->|input2| State4;

In Software

In software, certain things can be modeled as FSMs, and when done so, makes their implementation/maintenance/extensibility significantly easier.

Examples include:

• User interface navigation (e.g. different screens/states)
• Game character behavior (e.g. idle, walking, jumping)
• Protocols (e.g. TCP connection states)

GoF State Pattern

The Gang of Four (GoF) State Pattern is one implementation of a FSM in software.

First, identify (methods) that depend on state. This is usually input/event handlers, and process()/update() type of methods. Some examples:

• on_key_pressed()
• on_mouse_clicked()
• update(dt)
• on_message_received()

Then create an interface with these methods.

from abc import ABC, abstractmethod

class HeroState(ABC):
    @abstractmethod
    def on_key_pressed(self):
        pass

    @abstractmethod
    def update(self, dt):
        pass

Then, have the main object hold a reference to its current state. It should delegate state-dependent methods to its current state.

class Hero:
    def __init__(self):
        self._state = None

    def on_key_pressed(self):
        self._state.on_key_pressed()

    def update(self, dt):
        self._state.update(dt)

Generally, you want each State to have an enter() and exit() method to initialize/cleanup when that state is entered or exited.

You also usually want the Context class (Hero) to have a set_state() method. When a particular State, wants to change the state of the Context, it can call set_state() on the context. Obviously, this means each State needs a reference to the Context.

class HeroState(ABC):
    def __init__(self, context: Hero):
        self._context = context

    @abstractmethod
    def enter(self):
        pass

    @abstractmethod
    def exit(self):
        pass

    @abstractmethod
    def on_key_pressed(self):
        pass

    @abstractmethod
    def update(self, dt):
        pass

class Hero:
    def __init__(self):
        self._state = None

    def set_state(self, state: HeroState):
        if self._state:
            self._state.exit()
        self._state = state
        self._state.enter()

    def on_key_pressed(self):
        self._state.on_key_pressed()

    def update(self, dt):
        self._state.update(dt)

In GoF State Pattern, you encapsulate the data/behavior of each state in its own class.

Further Reading

This article was based on game programming patterns - state

Create a Basic Service

Let’s say you have a basic service with some endpoints.

from flask import Flask

app = Flask(__name__)

@app.route('/hello')
def hello():
    return 'Hello, World!'

@app.route('/goodbye')
def goodbye():
    return 'Goodbye, World!'

if __name__ == '__main__':
    app.run()

Basic Deploy

You can deploy your service to Cloud Run by running the following command:

gcloud run deploy --image gcr.io/PROJECT_ID/IMAGE_NAME --platform managed --concurrency 20 --allow-unauthenticated

Where:

• --image specifies the docker image of your service.
• --platform managed tells GCP to automatically scale the number of instances based on volume of requests.
• --concurrency specifies the max number of concurrent requests each instance should handle. GCP will spin a new instance if the number of requests exceeds this limit. Defaults to 80.
• --allow-unauthenticated allows unauthenticated access to your service.

You can optionally add --region REGION to deploy to a specific region.

This command returns a URL for your deployed service, which you can use to access it via HTTP.

Adding API Gateway (Cloud Endpoints)

Create an OpenAPI spec for Cloud Endpoints.

swagger: '2.0'
info:
  title: My Service
  description: My Service API
  version: 1.0.0
host: YOUR_API_GATEWAY_HOST
x-google-endpoints:
  - name: YOUR_API_GATEWAY_HOST
    allowCors: true
paths:
  /hello:
    get:
      summary: Hello World
      operationId: hello
      responses:
        '200':
          description: A successful response
          schema:
            type: string
  /goodbye:
    get:
      summary: Goodbye World
      operationId: goodbye
      responses:
        '200':
          description: A successful response
          schema:
            type: string

“Deploy” your API spec to cloud endpoints:

gcloud endpoints services deploy OPENAPI_SPEC.yaml

Deploy ESP (proxy HTTP server) to Cloud Run (in front of your service, which is also running in a Cloud Run instance):

gcloud run deploy espv2-gateway \
  --image=gcr.io/endpoints-release/endpoints-runtime:latest \
  --args="--config=/etc/endpoints/OPENAPI_SPEC.yaml,--backend=https://YOUR_CLOUD_RUN_URL" \ # <-- the URL of your service
  --platform managed \
  --allow-unauthenticated \
  --region REGION

This returns the URL of the ESP (proxy HTTP server), which is what you should ask clients to use when accessing your API.

Adding Authentication

In your OpenAPI spec, specify that authentication is required and the type(s) of authentication.

securityDefinitions:
    api_key:
        type: "apiKey"
        name: "key"
        in: "query"
    firebase_auth:
        type: "oauth2"
        flow: "implicit"
        authorizationUrl: "https://your-auth-server.com/auth" # documentation purpose only, clients must know this themselves
        x-google-issuer: "https://your-auth-server.com/"
        x-google-jwks_uri: "https://your-auth-server.com/.well-known/jwks.json"
        x-google-audiences: "https://your-auth-server.com/"
paths:
    /api/hello:
        get:
            security:
                - api_key: []
    /api/goodbye:
        get:
            security:
                - api_key: []
                - firebase_auth: []

Redeploy your service in cloud run but be sure to not specify --allow-unauthenticated.

Diagrams

Here are some diagrams that visually depict this “architecture”.

An API Gateway (ESP) sits between your clients and your service. Note that ESP is also running in cloud run:

flowchart LR
    Client[Client]
    ESP[ESP]
    Service[Service]

    Client --> ESP --> Service

The ESP just forwards requests from clients to the service:

sequenceDiagram
    participant Client
    participant ESP as ESP
    participant Service

    Client->>ESP: HTTP Request e.g., /hello
    ESP->>Service: Forwarded Request
    Service-->>ESP: Response
    ESP-->>Client: Response

If you have setup your ESP to authenticate (via the OpenAPI spec of your API), here is how authentication flow happens:

sequenceDiagram
    participant Client
    participant ESP as ESP
    participant Service

    Client->>ESP: HTTP Request e.g., /hello
    ESP->>ESP: Validate Token Using public Key
    alt Token Valid
        ESP->>Service: Forwarded Request
        Service-->>ESP: Response
        ESP-->>Client: Response
    else Token Invalid or Missing
        ESP-->>Client: 401 Unauthorized
    end

If token is missing/invalid, it is the job of the client to redirect to the identity provider, get a token, and try the HTTP request again:

sequenceDiagram
    participant Client
    participant Auth as Auth Server

    Client->>Auth: Redirect for Token
    Auth-->>Client: Token
    Client->>ESP: HTTP Request e.g., /hello

Summary

Basic (no authentication):

1. Upload the docker image of your service to Google’s artifact registry.
2. gcloud run deploy your service to deploy it in cloud run; you get back a URL to access it through.

With Authentication:

1. Create an OpenAPI spec for your API, specifying the authentication methods you want to support (token-based, external identity provider, etc.)
2. gcloud run deploy your service to deploy it in cloud run; you get back a URL to access it through, don’t provide this to clients.
3. gcloud endpoints services deploy your OpenAPI spec to create/update the API config.
4. gcloud run deploy your ESP (proxy) service to Cloud Run. You’ll need to specify the URL of your service as the target of the proxy.

sequenceDiagram
    participant Client
    participant Server
    participant IdentityProvider

    Client->>Server: Request without token
    Server-->>Client: 401 Unauthorized, redirect to IdentityProvider
    Client->>IdentityProvider: Login
    IdentityProvider-->>Client: JWT Token
    Client->>Server: Request with token
    Note right of Server: Server verifies token signature using public key from IdentityProvider
    alt Token valid
        Server-->>Client: Access granted
    else Token invalid
        Server-->>Client: 401 Unauthorized
    end

This is also refered to as “third-party authentication” (3PO).

BLUF: Unit Tests Should Only Break If Class Under Test Breaks

Unit tests should only break if the class under test breaks, not if one of its dependencies breaks.

When you see a unit test failing, assume that the code/logic of the class under test is failing, not the code/logic of one of its dependencies (assuming the unit tests were witten properly).

How do you ensure that your unit test only fails if the class under test fails? Simple: mock/fake its dependencies.

How you should mock/fake (and which you should use) depends on that particular test case. Assume a particular test case and a particular dependency.

Class to Dependency Communication

If in that particular test case, and for that particular dependency, communication is only from the class under test to the the dependency, i.e., the class under test calls the dependency’s methods, not the other way around, use a mock. Mock the dependency and assert the correct methods were called with the correct type/values. Simple.

Dependency to Class Communication

If the dependency needs to communicate with the class under test, use a fake.

A fake is a lightweight implementation of the dependency that behaves like the real one but is easier to control and set up for testing. It also only implements methods/functionality that is needed for that test case!

Example

In python, you can easily create fakes that have certain attributes mocked! This allows creating fakes extremely easily.

import pytest
from unittest.mock import MagicMock

class Publisher:
    def __init__(self):
        self.subscribers = []

    def subscribe(self, subscriber):
        self.subscribers.append(subscriber)

    def notify(self, message, *args, **kwargs):
        for subscriber in self.subscribers:
            subscriber(message, *args, **kwargs)

class FakeWebsocketServer:
    def __init__(self):
        self.on_client_connected = Publisher() # faked
        self.on_client_disconnected = Publisher() # faked
        self.on_message_received = Publisher() # faked

        self.broadcast = MagicMock() # mocked

def test_lockstep_server_sends_welcome_message_when_client_connects():
    websocket = FakeWebsocketServer()
    lockstep = LockstepServer(websocket)

    # simulate client connecting ("message" going from dependency to class under test)
    websocket.on_client_connected.notify("client1")

    # assert that the lockstep server sent a welcome message
    websocket.broadcast.assert_called_once_with("Welcome client1!")

In the above example:

• FakeWebsocketServer is a fake WebsocketServer implementation.
• It has some fake implementations and some mocked.
• The events on_client_connected, on_client_disconnected, and on_message_received are faked, because our class under test listens to these events, so they need actual subscribe methods and when we emit events on them, we need to ensure the class under test receives the emitted events.
• The broadcast method is mocked, because we just have to ensure this is called.

Integration Tests

To reiterate, unit tests should only break if the class under test breaks, not one of its dependencies.

If you want tests that check whether multiple classes work together correctly, write integration tests.

Generally keep these seperate from your unit tests, something like:

/src
/tests
    /unit
    /integration

Summary

• Unit tests should only break if the class under test breaks.
• Mock dependencies when the class under test only calls their methods.
• Use fakes when the dependency needs to call back into the class under test.

In lockstep multiplayer games, all clients must start executing the simulation at the same exact time. Once the server has connected with the expected number of clients, it will broadcast a “start executing the simulation at time t” message to all the clients. Each client may receive this message at a different time, but ultimately they will all start the simulation at the same exact time.

This sounds a bit easier than it is (thought it ain’t that hard).

Naive Solution

The immediate solution that may have popped into your head is to use some universal measure of time (agnostic of timezone). That way, all clients, irrespective of their local time, could start the simulation simultaneously. However, the problem with this is that the clock on each client may be slightly out of sync (by milliseconds) due to clock drift.

Clock Drift

Timers in hardware usually have an oscillating crystal that is used to keep track of how much time has passed. The crystal oscillates at some known frequency (say 32.768 kHz for a typical crystal), and the number of oscillations is counted to measure passage of time. The problem is, that the frequency of oscillation is not perfect (i.e. not exactly 32.768 kHz), there is some margin of error. This means that two timers over time will drift apart and begin showing different times. How fast they drift depends on the margin of error in their crystals.

Time Syncing

If this is true, why is it your phone and computer time don’t keep on drifting apart until they show different minutes? Because both devices periodically synchronize their clocks with a more accurate time source, such as an NTP (Network Time Protocol) server. The more frequently two devices sync with a common time source, the less drift they experience.

Time Syncing is not Good Enough for Multiplayer Games

In multiplayer games, you are dealing with extremely tight/sensitive timing constraints. If you’re lockstep simulating at 60 ticks per second, that means you only have about 1/60 or 16 milliseconds per tick. With common PC timer crystals, two computers can drift about 20 ms in 10 minutes (if they don’t sync with a common time source during that time).

So, we have to find a way to deal with, to “cancel out”, this clock drift. In other words, we have to find a way to measure the clock drift between two devices (so that we can compensate for it).

Computing Client Offset

The difference between two device’s timers is called an offset. For our two devices, let’s consider a server and a client.

You send a message from the client to the server, which sends a message back to the client. We’ll record time at each point.

• \(t_0\) is the time when the client sends the message (in client time)
• \(t_1\) is the time when the server receives the message (in server time)
• \(t_2\) is the time when the server sends the response (in server time)
• \(t_3\) is the time when the client receives the response (in client time)

Assume \(\theta\) is the offset between the server and the client, meaning (all equivalent):

Where:

• \(t_c\) is the time on the client
• \(t_s\) is the time on the server
• \(\theta\) is the offset between the server and the client

Server’s receive time in client frame is:

Thus uplink time (time for packet to go from client to server) is:

Server’s send time in client frame is:

Thus downlink time is:

If we assume that the the network is “symmetric” (uplink time is equal to downlink time):

Let’s simplify:

Rearrange to solve for theta:

Thus:

Conclusion

To find offset (theta) between the client and the server, we send RTT packets (Round Trip Time packets) and use the timestamps to compute the offset. We keep doing this for several packets and take the median (to avoid outliers).

This “jump into code” approach has its benefits, but also its downfalls, but those downfalls can be mitigated by following certain habits.

🎉 Benefits

Often, you have a lot of initial excitement when you first think of an idea. Jumping right into the code allows you to leverage that excitement/motivation to make progress quickly.

This allows you to quickly see what works, what doesn’t, what is fun, and what isn’t.

⚠️ Downfalls

The main problem I face with this wild west approach is that I often lose focus on priorities. I end up implementing nice-to-haves instead of core features.

The other issue is when I take a break for a few days, I forget what I was doing, and what I should do next. I also have to re-read/skim the code to understand high level design/architecture, and “how it works”. I really think I can benefit from some visuals about high level design/architecture/how-it-works, especially after breaks.

🛠️ Mitigation

Just to re-iterate, I still want to follow the low planning, high execution approach, but I want to mitigate the downfalls stated above.

📝 Do a 5-15 Minute Planning Session

In order to mitigate the “losing focus on priorities” problem, I will spend about 5-15 minutes planning before I start the project, I’ll write down:

• Overall, one statement goal of the project. E.g. “A tool that gives you visual context as you browse your codebase.”
• The core features that I want to implement.
• Questions I may have. This is to try to illicit risks early on. What are the different approaches to do X? What libraries are available?
• The nice-to-haves that I can implement later.

Remember, you should only spend 5-15 minutes on this. You will get it wrong, but that is okay. It’ll still help a lot.

🗒️ Write Brief Note Before Ending Each Session

To mitigate the “forgetting what I was doing” problem, I will jot down a note before the end of each session explaining what I was working on, and what I should do next. I can write this note in a sticky, or if I am using a lightweight kanban, I can write it as a comment on the card I’m currently working on.

🏗️ Write High Level Design/Architecture/How-It-Works

In order to mitigate the “needing to re-read/skim the code to understand it” problem, I have a few ideas.

For one, I can write a high level design description, a “how it works” in the README and maybe include a hastily drawn diagram.

I can also leverage AI each time I need to re-understand the code. Especially for small codebases, which most personal projects are, I can pass the entire codebase to the AI (or at least the entire repo map) and ask it to explain me the high level design and data flow.

Sometimes I don’t need diagrams, I can just explain with words, but I need to ensure that I use formatting (headings, bold, frequent blank lines), structure, and even emojis to make it more engaging (for myself) to read. Just staring at a wall of text is hard. I want to emphasize the importance of frequent blank lines. It makes it much easier for me to read.

Async/Await in Python vs C#

In Python, all coroutines are run a single thread (the event loop thread), which means that there is absolutely no risk of data races (of course, there is still the risk of other race conditions, which we’ll talk about later).

In C#, different coroutines may run simultaneously on different threads. This is because coroutines in C# run in a thread pool. So you can have data races.

Common Race Conditions

Let’s assume you are using async/await in an environment where you can’t have data race. What are race conditions that can still occur? These are basically all race conditions that are not data races lol. Let’s go over some of the most common, so that you can recognize/avoid them in your async/await code.

Check-then-Act

This is when you check a condition, and then act, but in between the check and the act, the condition may have changed (by another coroutine).

Here’s a classical bank account example:

async def withdraw(account, amount):
    if account.balance >= amount:  # Check
        await asyncio.sleep(0)  # Yield control to the event loop (other coroutines may run here)
        account.balance -= amount 

account.balance = 120
await asyncio.gather(withdraw(account, 100), withdraw(account, 100)) # may succeed and leave account.balance = -80

Two coroutines can both get past the check, withdraw money, and you may end up with a negative balance.

To avoid this, make sure both the check and the act are done atomically. You can do this either by not putting an await between them, or by using a lock (asyncio.Lock in Python).

Read-Modify-Write

This is when you read a value, modify it, and then write it back. If another coroutine modifies the value in between the read and the write, you may end up with an incorrect value.

Here’s an example:

async def increment(counter):
    value = counter.value  # Read
    await asyncio.sleep(0)  # Yield
    counter.value = value + 1  # Write

counter.value = 0
await asyncio.gather(increment(counter), increment(counter))  # may end up with counter.value = 1

Again, to avoid this, you can either not yield control between the read and the write, or use a lock.

Event Ordering Dependencies

This is when you are depending on the order of execution of your coroutines. The problem is, in Python, this order is not guaranteed.

The best solution here is to avoid depending on the order of execution of coroutines. If you must, you can use asyncio.Event to signal when a coroutine has completed its work, and then wait for that event in the other coroutines.

Lock Starvation

This is when a coroutine is waiting for a lock, but other coroutines keep acquiring the lock. In Python (and in underlying Operating Systems), lock acquiring is not fair, meaning that the one waiting the longest may not be the one to acquire the lock next. Thus anytime you use a lock, you should be aware of the possibility of starvation.

Javascript Note

Both Python and Javascript use a single-threaded event loop for async/io, so in Javascript as well, you don’t have to worry about data races.