The Javascript party line is that you don't need locking, because no threads, no safety, no problem: every window or tab has its own Javascript context, and that context is guaranteed to behave as if it is single-threaded: sequential execution, timers fire on return to the event loop, processes cannot communicate with each other.

Except then they added localStorage. Oh, what's this? Is it shared memory that can be accessed asynchronously by multiple contexts? Why yes it is! So now you really do need locking. Except then they didn't add mutexes, or even an atomic-read-and-increment operator. Hooray. And they also didn't add any IPC, like a socket that one process can write to and that others can select() on. Hooray.

So let's say you've got an app, it spans multiple documents, and you want a sound to play in reaction to some external, asynchronous event if any of your documents are open. But if three windows are open, you only want that sound to play once per event. The obvious way to do this is to nominate one of those documents as the leader, and pass the conch to someone else if the leader document goes away.

Well, good luck with that, since you only have a shared whiteboard, not real IPC. This means that each of your contexts needs to constantly poll the whiteboard, doing something like, "Has it been too long since the leader has updated their heartbeat timestamp? If so, now I must race with my brethren to try and acquire the lock and become the leader." So aside from that being stupid -- all those timers, all that polling -- it's also inefficient, because it means that there's always an interregnum during which there's no leader (your polling interval). Try to burn fewer cycles by increasing your polling interval and you increase the window during which your asynchronous notifications can't happen.

What kind of Mickey Mouse operation is this? There was better multitasking on MacOS 6.

Oh, and speaking of sound: on iOS, you flat-out cannot play sound unless somewhere higher up on the call stack is a touch gesture. Asynchronous sounds can't be done using the HTML5 audio tag, because... Apple are dicks, I guess? I'm gonna go with that. So apparently there's a newer and completely separate audio interface with a way more convoluted API, and maybe that one works on iOS? But I haven't investigated, having at that point run out of fucks due to the fact that I was starting to have ALSA versus OSS flashbacks and expecting it to tell me my EMU10K1 PCM setting was wrong.

Previously, previously, previously.