Hackr News App

<@gf000> I've read a few postmortems about STM. I have to take them with a grain of salt because I usually read those reports right after doing a bunch of STM programming, and right before doing a bunch more STM programming. Reports of its death have been greatly exaggerated.

Here it is in 2006 featuring the same Tim from your article: https://www.youtube.com/watch?v=tve57vilywc

I didn't start using it in anger till 2013-2014 maybe? But I don't recall any major differences between what the video shows and how it works in 2025.

Anyway, postmortems usually boil down to two issues:

1) That's not how programmers usually do it

2) We couldn't pull it off

The most obvious explanation for 1 is 2. I, too, would be disappointed by the low-adoption rates of my new technology if I hadn't built it or released it to users.

But the article has some gems:

  Transactions unfortunately do not address one other issue, which turns out to be the most fundamental of all: sharing. Indeed, TM is insufficient – indeed, even dangerous – on its own because it makes it very easy to share data and access it from multiple threads;

  I already mentioned a great virtue of transactions is their ability to nest. But I neglected to say how this works. And in fact when we began, we only recognized one form of nesting. You’re in one atomic block and then enter into another one. What happens if that inner transaction commits or rolls back, before the fate of the outer transaction is known

  Then that same intern’s casual statement pointing out an Earth-shattering flaw that would threaten the kind of TM we (and most of the industry at the time) were building. ...
  An update in-place system will allow that transaction to freely change the state of x. Of course, it will roll back here, because isItOwned changed to true. But by then it is too late: the other thread using x outside of a transaction will see constantly changing state – torn reads even – and who knows what will happen from there. A known flaw in any weakly atomic, update in-place TM.

  If this example appears contrived, it’s not. It shows up in many circumstances.

<@gf000> Given your example, I am convinced you've never written any Rust. Of course it does stop you doing shit like that. But in this example, even Java does it properly, since the constructor runs to completion before any Object is accessible to any Thread, not just the one creating it. You need to validate the state of the object in the constructor to prevent that, but TBH why are we talking about this, it's almost completely unrelated to concurrency models.

<@nlitened> I agree that messy reality can intervene, in the medium term (for about a decade) we'll need to handle leap seconds

But we can do a lot without challenging the messy reality. 61 second minutes are (regrettably) a thing in some time systems, but negative 1 million second minutes are not a thing, there's no need for this to be a signed integer!

<@gf000> > much of a win?

It's a huge win. Absolutely game changing.

> You just made a bunch of concurrent algorithms un-implementable

Exactly! That's a good thing! You think you need those buggy algorithms, you just don't, at least in 99% of cases.

Yes, you can still end up with inconsistencies when you perform actions without the necessary checks, but those cases that remain are extremely easy to find and fix (and even make completely impossible by design), when compared to the horrors of mutable state with locks.

<@jbritton> There's no confusion.

<@brabel> In Java, racing a field is safe - you can only ever observe the value as one that was explicitly set by a thread, no tearing can happen. Safe data races can happen in Java, but you sometimes do want that (e.g. efficient concurrent algorithms), and avoiding it is not particularly hard (synchronized blocks are not the state of the art, but does make it easy to solve a problem).

Pony and Rust are both very interesting languages, but it is absolutely trivial to re-introduce locks with actors, even just accidentally, and then you are back at square 1. This is what you have to understand, their fundamental model has a one-to-one mapping to "traditional" multi-threading with locks. The same way you can't avoid the Turing model's gotchas, actors and stuff won't fundamentally change the landscape either.

<@aoli-al> any chance you can make light/dark mode switch a UI button?