Forem: Iouri Khramtsov

Multi-threading without locks

Iouri Khramtsov — Tue, 11 Feb 2020 00:42:19 +0000

Just because you're sharing data structures between threads doesn't mean you have to use locks.

Over the years I've come across a few approaches that help coordinate work between threads without having to make anyone wait. Here are a couple of them.

WARNING: I stopped using these patterns because they are easy to misunderstand and misuse, which can lead to random hard-to-diagnose bugs. If you use these patterns, you're not helping the next develper understand the code better or avoid mistakes. You have been warned.

Reference to an immutable object

We know that in a multithreaded environment, modifying a shared object without locks is a bad idea. But what about replacing it?

For example, consider this code. I'll use C#, but the same applies in Java, C++, or another traditional language with threads.

public class FunWithThreads {
    private Thing thing;

    public void InThreadOne() {
        this.thing = new Thing()
    }

    public Result InThreadTwo() {
        var localThing = this.thing;
        var result1 = SomeCalculation1(localThing);
        var result2 = SomeCalculation2(localThing);
        var finalResult = DoMoreWork(localThing, result1, result2);
        return result;
    }
}

Suppose lots of threads are concurrently calling InThreadOne(), while lots of other threads are concurrently calling InThreadTwo(). Will we ever get a wrong result, a race condition, or a conflict?

Not really. InThreadTwo() always refers to a consistent version of this.thing because it places the reference to it into a local variable, and from then on uses only the local reference. If the calculations take too long, then maybe we get a result that's a bit stale, but that result will always be consistent.

Where it's useful: I found this approach to be useful whenever this.thing is a large, pre-computed data structure that gets infrequently updated but frequently read. Mostly I've used it to cache some data for internal capital markets applications to make the application feel snappier to the user.

The pitfalls: It's really important to make sure that this.thing is referenced only once at the beginning of the method, or else we're back to race conditions. It's also really important that this.thing is never modified after it's assigned. That means lots of descriptive comments, very careful code reviews, and making sure that every developer that ever looks at this code knows all the gotchas. In a larger codebase, someone (maybe even you!) might still find a way to make a mistake somewhere.

Complex atomic operations

The reason the above code works is because in C# (and in most other languages) assignment of references is an atomic operation, i.e. while it's executing, another thread can't sneak in mid-way and do something else.

Modern processors have a few other interesting atomic operations, like compare and swap, implemented in C# as Interlocked.CompareExchange(), and in Java as AtomicInteger.compareAndSet(). This function takes three arguments and does the following as an atomic operation:

Compares the first and the third arguments, then
If they're equal, sets the first argument to be equal to the second argument, or
If they're not equal, does nothing.

One case where this can be used is when trying to limit requests for an expensive operation on a limited resource. For example, this code will drop any requests if the expensive operation is already running:

// Let's pretend this class is a singleton.
public class ExpensiveOperationLimiter {
    private int isProcessing = 0; 

    public void RequestExpensiveOperation() {
        // If isProcessing == 1, this does nothing and returns 1.
        // If isProcessing == 0, this sets isProcessing to 1 and returns 0. 
        var wasProcessing = Interlocked.CompareExchange(ref isProcessing, 1, 0);

        if (!wasProcessing) {
            // Only one invocation will be running at a time.
            DoExpensiveOperation()
        }

        isProcessing = 0;
    }

    private void DoExpensiveOperation() {
        // ...
    }
}

If you look at the above code carefully, you'll see that you can't replace Interlocked.CompareExchange() and still have thread safety - there will always be an opportunity for another thread to sneak in between the instructions.

With a bit of work, this code can also be expanded to queue up the next request.

Where it's useful: I've used this kind of code in situations where events can randomly trigger an application server's cache to refresh from a database or from another system.

The pitfalls: Generally, I'd consider this to be a micro-optimization and not worth the effort. Many developers understand or have heard of locks, and have an easier time following them than any code that involves compare-and-set. As before, by using this, you're risking someone (including you!) eventually making a mistake.

The best way to avoid locks

Don't write multithreaded code!

A shameless plug

Check out Maesure, a time tracker that asks you every 10 minutes what you're doing.

Show DEV.to: A time tracker that asks every 10 minutes what you're doing

Iouri Khramtsov — Mon, 10 Feb 2020 23:05:30 +0000

What it is

Maesure.com - can use it without signing up, though it's better to sign up.

Here's what it looks like when you use it for a while:

But why?

I tried a few ways to track time in the past using Excel spreadsheets and various apps. Usually I couldn't stand using it for more than a few days. Eventually I decided to try this approach — and surprisingly, it worked.

It's less annoying that it seems at first glance. The first few times the interruptions are a bit jarring, but once you get used to it, you mostly don't notice it anymore. After a day or so, you will be able to answer most of Maesure's popups with one click or two keystrokes because it will accumulate a list of your most recent answers.

Who uses it

So far, it's been most popular among people who must track their time for work, either to bill clients or to report time on projects.

A few, including me, have used it to improve personal productivity. I've written about my approach here.

Future plans

Eventually there will be a paid version, though that's still some time away. In the meantime, feel free to let me know what's working or not working for you - I try to respond quickly to the users

Cheers and happy Maesuring!

How to make your codebase age well - an architect's perspective

Iouri Khramtsov — Fri, 31 Jan 2020 13:15:36 +0000

Why are some systems easy to update after a decade, while others are hard to understand after a year or two? And why are some companies drowning in bugs and need a month to complete a change that takes days in other companies?

Some of the root causes may be organizational, but technical choices also make a big difference.

After seeing plenty of projects on either end of the spectrum, here are the biggest differences between codebases that age well and the ones that don't.

1. Have less stuff to maintain

The most maintainable systems I've seen had architects that pushed for:

Fewer features by being choosy about which features to implement
Fewer technologies rather than more - e.g. avoiding polyglot microservices
Sticking to the same patterns over time, even if they're imperfect (but good enough)
Fewer services, technologies, 3rd party components, etc
Fewer lines of code, relying more on third-party libraries and services
Cleaning up old unused parts
Fewer moving parts overall

Whatever is left would ideally be organized into groups of very similar-looking components so that whoever works on the system in five years would be able to understand it easily.

The reverse of this — a technology/feature/sub-system sprawl — is one of the scariest ways in which the system can become unmaintainable because it is difficult to reverse. This can happen when generations of programmers come through an organization, decide that the old way of building things is bad, introduce new technologies/patterns/systems without replacing the old ones, and then are replaced by the next generation. Or by multiple teams working in parallel, independently picking their favorite tech stacks. To a lesser degree, this can happen when less experienced teams keep adding new tech to the mix without thinking through the complexity that comes out.

Either way, the end result is a system that's hard to fully comprehend, easy to break, and probably has team members that can't or don't want to touch unfamiliar parts of the system.

2. Choose mature, popular technologies

If you want your codebase to be easy to update in five years, don't use a technology that will be dead in five years. Or one that will change so much that upgrading becomes impractical. Anything built on Angular 1, Silverlight, or early milestone Spring Boot versions would be very uncomfortable to work with today.

For this reason, I prefer to pick popular technologies that are already on v2 or v3 and have largely stabilized.

As of early 2020, this means:

React: Good. Popular, widely used, about six years old. Probably the best pick on the front end.
F#: Bad. Mature, but not widely used. Avoid unless you already have F# experts, or it's a solo side project.
Svelte: Bad. Popular, high satisfaction, but new; might not survive or might change a lot in the next few years.
C: Good. Will likely outlive all of us. Safe choice for its use cases.

There are a number of other, immediate advantages to picking popular, older technologies over newer or less popular ones:

More and better tools + libraries
Lots of Stackoverflow answers to frequent problems
Easy to find developers who can work with it

There are several variations on this theme; one of my coworkers calls himself "Service Pack 2 guy" (service pack 1 is too early for him). Choose boring technology is another popular essay that expands on this.

3. Tests, tests, tests

At my new job, about a month into it, I needed to update a service written in Python that was rarely touched by others. It was written over the past few years, and the original authors have left the company some time ago. After spending some time browsing around the source code, I discovered that not only did it have great comments, but also 98% unit test coverage! In addition, it was part of a massive integration test suite. A couple weeks later when I was done, I was extremely confident that I didn't break any existing functionality, and that my new additions would probably work as expected.

While automated tests can slow you down in the short run, on systems that have a long life they're totally worth the effort.

I find that the tests that give the most return for the effort are:

Unit tests, because they're easy to write and run, and
End-to-end tests on the whole system, because they can uncover most integration issues and prove that the entire system works as expected.

In some cases, the latter type can also be run in production after deployments to catch problems early.

4. Help the next developer understand the system

Whether it's a new developer joining a 100-person dev org, or a single dev looking at the source code that has not been touched in the past five years, they'll have a hard time modifying a system when they don't know what it does or why.

So help them out in advance. This means:

Don't surprise them with unexpected side-effects
Leave comments that explain the "why"
Have clear names
High-level documentation

Who knows, the next developer could even be you!

A shameless plug

Check out Maesure, a time tracker that asks you every 10 minutes what you're doing (the period is configurable). It seems to be most popular among those who have to track time for work, though a few are using it for their personal life.