The easiest way to write programs that support concurrency is to not. JavaScript in the browser is famously single-threaded, unless you add web-workers, which have a very specific way of interacting with your main script that avoids most of the pitfalls of concurrency. Or at least makes them easy to avoid.

But what if you had a developer who didn't know any of this, and just assumed JavaScript was multithreaded and needed locks, but didn't understand how locks worked? Then you'd get something like this code, from an anonymous submitter.

var lock = false;

function Initialize() {
        if (lock) {
                // Code...
        } else {
                // Code...
                lock = true;
                // Code...
        }
}

Since there aren't multiple threads, this isn't necessary. So the code is stupid on its face, but it's actually advanced stupid. First off, check/assign of a variable wouldn't be atomic anyway, so the lock wouldn't act as a lock anyway. But they don't even attempt any sort of atomicity, as the code which takes the lock is in the middle of the else-block several lines away from the check.

So the code doesn't do anything, but even if it did, it'd be wrong. And even if it weren't, it'd still be wrong.

You'll be shocked to learn that the lock is "released" in an entirely different function, making it even more wrong.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!