Software

Azure Blues

It isn't very often I get to apply Moore's Law to a non-Information Technology business and rarer still that I can then relate the whole thing back to Microsoft, so I'm going for it. Here's what the solar power industry can teach us about Microsoft:

The wonderful thing about Moore's Law is what the lady at the bank called the "miracle of compound interest." That halving of manufacturing cost every 18 months (the OTHER way of looking at Moore's Law that we generally don't use) has little apparent impact in the first few years, but eventually the halving and re-halving takes a real bite out of the cost side until substantial performance is very, very cheap. That explains why there is more computing power -- a LOT more -- in your iPod than was required for the Apollo Moon missions. Well this applies to ALL silicon-substrate photolithography applications, not just computer chips. It applies equally well, for example, to silicon solar cells.

There are many types of solar cells. Some solar cells involve crystalline silicon just like computer chips and others use amorphous silicon, but all types benefit from Moore's Law. In fact one especially good aspect of solar cells is that they can make use of older process technologies that are obsolete for computer work. So every time Intel or AMD builds a new fab there is a market in the solar industry for their old machines. Look at those round solar cells used in many arrays today and you'll notice the smaller wafer sizes favored in Silicon Valley 15-20 years ago. That's no coincidence.

The result of this relentless application of Moore's Law to the solar industry is that we can see a time in that near future when the cost of producing a watt of electricity from a solar cell on your roof will be approximately the same as the cost of delivering that same watt over a power line from an electric utility. And of course that means that 18 months after that point the solar watt will cost HALF of what the same power would cost from the electric company, which will completely change the game.

The time when that electricity cost parity will be reached, I'm told, is seven years from now. Just think of the impact that will have on electric utilities! Why would any of us continue to buy our power from them? We might use them as a giant storage battery and possibly for backup on cloudy days, but why would we use them at all for power if we can generate it cheaper at home? You can bet that's a question the electric power generating industry is asking itself.

The whammy for the power companies is two-fold, because not only will power be cheaper but, by definition, the cost of building and installing solar panels will be substantially cheaper, too, than it is today. If it costs $40,000 on average to refit your house today, a lot of homeowners can't afford that, but what if it becomes $10,000? That's what worries electric companies that are used to having easier access to capital than do their customers. But once installing solar power costs relative chump change (the cost of a nice Ski-Doo or remodeling a bathroom), we'll see massive conversion and the power companies know that.

So what can they do? They can find ways to get us to use more power than can possibly be generated from the roof of a typical American home. And that's why this week the Electric Power Research Institute proposed that we all get plug-in hybrid cars. It would save billions of barrels of oil, they say, lower greenhouse gas emissions, clean the air, oh and by the way require more electricity than your solar cells can produce, thanks.

And it will work -- for a while. But Moore's Law is relentless, you know, and the role of electric utilities will change dramatically over the next decade as a result. As far as I can see, this is all for the better.

But what does it have to do with Microsoft?

Well that brings us to Windows Azure, which was still called Windows Cloud when I first mentioned it a couple weeks ago. Like all Microsoft strategies, Windows Azure is a reaction to external competitive pressures. And it is important, VERY important. Here's how a source of mine at Microsoft put it a few days ago, before the Azure announcement: "The cloud stuff isn't just another enterprise product. It is going to impact everything we do -- all of the product groups -- consumer and enterprise -- are going to have to figure out where they fit in to the cloud paradigm. The shift to cloud-based computing is analogous to our shift to the Internet in the late '90s. It changed the direction of the company and impacted everything we did."

Wow, that's a big deal! Yet based on the Microsoft announcement this week, all Windows Azure looks like to me is Microsoft's effort to sell web services or maybe cut the sticker shock for smaller businesses adopting SQL Server. But more properly, it likely means Microsoft's acceptance that computing clients may eventually be free or nearly so. In short, Windows Azure is an insurance policy against the possible Vista-like failure of Windows 7.

Last week, for example, I wrote about Microsoft's Windows Mobile technology, predicting that it would die simply because Redmond would realize that it could never be first or second in market share. That was no big scoop from me, though some news people took it as one -- it was just common sense. And so what happened this week? Well here's a report from a reader attending Microsoft's Professional Developer Conference, where Windows Azure and Windows 7 were introduced this week.

"Windows Mobile has (a) near zero presence at MS PDC," wrote the reader. "Their Live Mesh platform has Windows Mobile as an integral component but otherwise no mention, no sessions. There was one session scheduled but it was cancelled at the last minute. Hmmm."

When the body is under stress, it eventually sacrifices entire limbs to keep the internal organs working. Windows Mobile is just an appendage to Microsoft and always has been. Yet mobile is clearly the client of the future, so what's to be done? Windows Azure. Control the back end through industry standard -- even open source -- protocols. Make money from subscriptions and ads -- make money any and every way in the hope of leveraging a global infrastructure investment into a continuing business strategy.

Can you see the connection here? There is almost no difference between Microsoft trying to become our computing utility and the electric company trying to power our next-generation cars. Both are coping strategies, both are risky, but neither Microsoft nor the electric utilities see that they have any real choice. And maybe they don't.

For Microsoft, at least, it could be a strategy with legs. While the utilities will be undercut more and more by Moore's Law, Microsoft as a computing utility won't be. But that doesn't mean they'll be any good at the job. It means fighting a war on two fronts -- with Google as a provider of applications and with Apple as a provider of content. MAYBE Microsoft has a shot against Google, which is becoming more Microsoft-like itself by the day, but to compete with Apple as a content provider? Forget it. Microsoft simply isn't the class act it needs to be to dominate that space, so look for acquisitions to (maybe) fill that void.

And all this means that Windows 7 had darned well better hit a home run or Microsoft is in BIG trouble.

Audio mixing with VMWare on Linux host

Ever since I switched to VMware from VirtualBox I have had a problem with audio.  If I launch VMware after launching an application that has played some audio, the audio will not work from guest OS.  Also, if I launch VMware first, no Linux application will be able to play audio.

It looks like the problem is that VMware is using OSS for audio, while the sound mixer that Ubuntu uses is ALSA.  This forum has instructions to get this to work.  Essentially the solution is to use the alsa-oss library to have VMware audio go through alsa.

Collateral Damage

I am not a very sophisticated mobile phone user. I don't use most of the bells and whistles on my phone, probably because I don't know what they even are. But just because I'm an idiot about USING mobile phones doesn't mean I don't understand the emerging mobile market, to which I have been paying a lot of attention of late. And why not? As personal computers fade from what Al Mandel called "ubiquity to invisibility," something has to take over. And everyone I respect thinks the new dominant platform will be mobile. So it's my job to tell you, then, that Windows Mobile is probably doomed.

Interestingly, this conclusion isn't based on any personal preference or subjective analysis. I'm not saying that Windows Mobile is bad, just that it is probably doomed. It's a simple matter of market economics.

There is generally room in any technology marketplace for three competing standards. Notice I say "standards," not "brands." There can be many brands of road vehicles, but they generally come down to cars, trucks, and motorcycles -- each a standard. In personal computers we have Windows, Macintosh, and Linux (or similar Unix workstation variant). In HVAC systems, just to stretch the point, there are radiant, forced air, or evaporative systems -- again three standards.

And among those three standards there tends to be a market-share distribution that is more or less 85-10-5. These numbers can jump around a bit and one can argue that the Mac is now more than 10 percent of recent sales, though not of the installed PC base, so I hope you get my point. This magic 85-10-5 distribution also happens to mirror what happens at the racetrack or in the casino, where 85 percent of gamblers lose, 10 percent break-even, and 5 percent are winners, which explains all those big buildings in Las Vegas.

The mobile phone marketplace shows a similar distribution, though that now appears to be in some transition. One could argue that the old 85-10-5 came down to basic or dumb phones (85), smartphones (10), and specialized or vertical phones like the old Nextel (5). Moore's Law now seems to be inexorably turning all phones into smartphones, so we're probably moving toward an 85-10-5 based on programming platform.

Let's consider this smartphone migration for a moment, first with Samsung in mind. Last week Samsung announced that it would no longer be making high-end phones and would stick to basic phones in the future -- going for higher volumes at lower cost. This makes a lot of sense given that sophisticated phones must cost more to develop yet tend to be more expensive as a result and therefore have lower sales numbers. So why bother? This was the message Samsung sent out and everyone bought, but I really think that if you look at it in the context of a dynamic market the announcement means something else altogether.

Deconstructing the Samsung announcement we'd have to wonder how the company sees itself and its competitors. That answer is pretty simple: Samsung sees itself as a global electronics company competing with outfits like Sony. Samsung has been for 40 years all about copying and eventually crushing Sony. Now given that's how Samsung sees itself (nobody I know contests this vision, by the way), how can the company possibly afford to let Nokia, Motorola, Sony, and Apple make high-end phones, which is to say smartphones, without Samsung competing in that space? That would be giving up a lifelong dream and Samsung just won't do it.

So were they lying?

No, Samsung wasn't lying, they were just doing what my old friend, PR man Martin Quigley, called "dissembling." Samsung probably has no intention of abandoning the smartphone market because ALL phones are becoming smartphones. What they truly intend to do, however, is make smartphones that are generally inexpensive, hoping to gain market share as a result. We'll see this trend from Apple, too, which will push iPhone prices down and introduce cheaper models next year and beyond.

While there are many ways for Samsung to make smartphones less expensive, the easiest way to do so and yet remain competitive on features is by no longer using software that costs money.

In the smartphone space there are, at present, only three operating systems that are being broadly licensed on an OEM basis -- Android, Symbian, and Windows Mobile. Of those three, two are free -- Android and Symbian. Symbian didn't used to be free but times change and now it is.

So Samsung was announcing that it would be ending development of Windows Mobile devices at some point, though they never said that directly.

Sticking with Samsung for a moment, then, which of the two free software platforms is the company likely to endorse? That's a good question. Symbian has a very strong presence in Japan, which is an important market for Samsung, so I don't see them abandoning Symbian immediately. But in the longer term I think Samsung WILL abandon Symbian, as will most of the rest of the world.

Here's why (donning flameproof clothing): Symbian is simply too old. The OS is getting slower and slower with each release. The GUIs are getting uglier and are not user-friendly. The development environment is particularly bad, which wouldn't hurt if there weren't others that are so much better. Symbian C++, for example, is not a standard C++. There is little momentum in the Symbian developer community, maybe because coding for Symbian is a pain. Yes, there are way more Symbian phones in circulation, but those phones will be gone 18 months from now, probably replaced by phones with a different OS. Lately, Symbian's success has been primarily based on the high quality of Nokia hardware, on the loyalty of NTT DoCoMo, and now on the lure of being recently made open source and therefore free. But if open source developers don't flock now to Symbian (they aren't as far as I can see -- at least not yet) then the OS is doomed.

My guess is that in time Samsung, like Motorola, will devote its smartphone development 100 percent to Android.

Maybe, but what about Apple and RIM, what will happen there? This is not a time to bet against the iPhone, which is changing the entire landscape of not just smartphones but mobile phones in general. For all its teething problems, there is a new sheriff in town and his name is iPhone. We'll see nothing but progress and market-share gains there for at least another two product cycles or three years.

RIM is another story altogether. What RIM has going for it are loyal users, good keyboards, and push mail. Most mobile phone users still think RIM is the only platform that has push mail. But given that push mail will soon be everywhere and the market will eventually figure that out, RIM is facing a huge challenge. I'm not saying they won't meet that challenge, I simply don't know.

If I had to bet right this moment on the mobile 85-10-5 of 2011 I'd say iPhone, Android, then RIM, Symbian, or something completely new from behind Door Number Three.

Why iPhone over Android? For exactly the same reason why the iPod holds that approximate 85 position among music players, including ones using open source software. iPhone has a really great SDK (light-years ahead of any other right now). The App Store distribution platform is great, but locked on too many points. This is a careful timing issue for Apple. If they open the APIs too quickly they risk being blocked. They need to open an API once they are perfectly sure it is the right one and the right way to export that function. Apple is going to relax the restrictions progressively when they better understand the use cases and what are the best APIs. In the meantime it is giving an advantage to Android, but one that I think a year from now Apple will have reclaimed.

And where will Windows Mobile be in 2011? There way things are headed now, given that Microsoft can't really afford to be anything but first or second on the platform that supplants Windows, I'd say Windows Mobile will be dead.

Ctrl-Alt-Del

Apple last week introduced a pair of very nice notebook computers that, not at all surprisingly, looked like riffs on the MacBook Air. The company in a separate announcement released 600 high-definition television episodes through the iTunes Store. This week Apple will reportedly release new 20-inch and 24-inch iMacs, also for the Christmas season. Two weeks, three announcements, but what strikes me (and apparently only me at this point) is what won't be announced -- the big surprises that are missing. What happened?

A MacBook and a MacBook Pro are nice, but not overwhelming. I like the dual GPU in the Pro and I hate the lack of a FireWire port in the MacBook, but beyond that there is little to say about these products except that the glass screens (on the iMacs, too) are better for houses like mine filled with LCD screen-destroying pre-school boys. These new products don't appear to break any price or performance barriers and sure as heck don't allow time travel or make me more handsome.

We were led to expect more -- a lot more. And I am not talking about rumors.

Back on July 21st in his regular conference call with industry analysts, Apple Chief Financial Officer Peter Oppenheimer said that Apple's profit margin would likely shrink from 34.8 percent in the just-concluded quarter to 31.5 percent in the quarter ending in September. "We've got a future product transition that I can't discuss with you today," Oppenheimer said as he spelled out the reasons for the anticipated profit reduction. "One of the reasons that we see gross margin being down sequentially is because of a product transition."

What kind of Apple product could be expected to come along, taking a $244 million profit hit for the company? It certainly isn't any of the products we've discussed so far, nor is it the iPhone 3G or the new iPod Touch, which have both been publicly dissected and found to have gross margins in the 56 percent range.

It's something else that was probably intended to be announced this week but wasn't.

The change of plan could have come for many reasons. Maybe the revolutionary product wasn't ready in time. Maybe introducing an aggressive, low-margin product in the middle of a global financial crisis was considered a bad risk. Maybe some strategic alliance had to be in place and wasn't ready. Whatever it was, the same analysts will ask about it this Tuesday when Apple has another such conference call scheduled.

But of course none of this keeps me from speculating about what's missing from Apple's announcements and the reasons it might be missing.

I think the delayed product has everything to do with Apple's desire for Blu-ray DVDs to die as a standard. Apple CEO Steve Jobs took a swipe at Blu-ray in last week's announcement -- a swipe that felt out of sync with the rest of the program. Steve has no difficulty at all NOT talking about subjects he wants to avoid, so leaning into Blu-ray was not at all offhand or without strategic importance. Don't expect Blu-ray drives on Apple computers, Steve said, yet he didn't offer a clear alternative.

The alternative Jobs would like to offer, of course, is full 1080p HD video distribution on iTunes, but that's not currently possible. It will happen in time, of course, but certain prerequisites have to be in place. Apple hardware has to support it in a practical sense, for one.

Interestingly, users of the new Apple notebooks began reporting that CPU utilization for H.264 decoding on their new machines dropped from 100 percent on an earlier model with the same processor to sub-20 percent on the new aluminum MacBooks. Though it wasn't announced, Apple seems to have (finally) enabled H.264 decoding on the Nvidia GPUs in these new machines.

Equally significant is the fact that ONLY H.264 appears to be accelerated. HD content using the MPEG-2 or VC-1 codecs seem to be not accelerated, which means this improvement is aimed specifically at Apple (iTunes) content, NOT physical media.

This is something we might have expected Apple to trumpet, but they don't offer any 1080p content yet other than movie trailers. Maybe it is better, Apple might imagine, to pre-seed this capability so more machines can take advantage of it when Apple 1080p content finally does appear.

What's yet to come, I'm guessing, is Apple's next OS X release, Snow Leopard, with QuickTime X -- the first version of QuickTime supposedly optimized for H.264 hardware decoding.

Snow Leopard is late, but then operating system updates are always late, no matter the vendor. This delay could be for any number of reasons and there are probably several, but one of them I can guarantee you has to do with H.264.

More than a year ago I made a big point of predicting that Apple would go to H.264 hardware acceleration, though I pinned it on a specific chip from NHK and NTT in Japan. This was after the usual evening of drinking with Japanese executives that typically reveals such information. Oh the sacrifices my liver makes for journalistic integrity!

So what happened to that NTT chip? I don't know. Maybe it was too expensive and fell out of the plan. Maybe it's in there still and Nvidia licensed technology from NHK and NTT to enable the new hardware acceleration (this is just a speculation -- I'm not at all saying they did). Maybe -- and this is the one I believe -- the discrete NTT chip was overtaken by a snowballing Apple strategy involving PA Semi, Apple's recently acquired division that designs microprocessors.

Here's the reasoning, which isn't all mine by any means. I have the smartest readers in the world and they are constantly giving me new things to think about.

First we see Apple moving away from Intel chipsets with these new MacBooks and probably with the iMacs to be introduced this week. Apple has always been involved in its own chipset design and giving up that capability to Intel until now didn't make much sense, especially considering the crappy Intel integrated graphics. It is logical to assume that Apple would reclaim its right to design or at least specify the chipset as soon as its internal engineering capability could support that.

Turning to Nvidia isn't the same as doing the chipset itself, but you can bet Apple's fingers are all over the chipsets in these new machines and that they are significantly different from those in notebooks from companies like Dell and HP.

There is a reason to be different here that goes beyond performance. That other reason is Psystar, the would-be seller of Mac clones with which Apple is now locked in a legal battle that could go either way. What if Psystar comes out on top and has the right to sell Mac clones based on the Hackintosh model? Then Apple will have to break that model by becoming more proprietary and therefore harder to emulate. Enter the third-party chipset, which is just the first step in Apple's effort to become immune to Psystar-type clones no matter what the court decides.

Second is Snow Leopard, itself. Apple has suggested that Snow Leopard won't have many new features but will be Apple's effort to more fully take advantage of multi-core processors. This harkens back to my parallel computing column of a couple weeks ago.

Snow Leopard, I'm told, will make seamless use of as many cores as are available. It isn't clear whether applications will have to be rewritten to take advantage of this capability, but I'm guessing they will have to be. This is just a guess, mind you, but is consistent with the sort of demands Apple likes to place on developers. Apple's own applications will be Snow Leopard-compatible you can bet, and will set a daunting performance standard in iMovie and Final Cut Pro.

Where PA Semi fits in is by providing to Apple a modular, Intel-compatible multi-core architecture that can scale to cover entire future Apple product lines. By dishing out more responsibility to the GPU, Apple can enable a much simpler CPU with as many cores as needed. Imagine a single core in an iPhone, two cores in an Apple TV, 2-4 cores in a notebook, 4-6 in an iMac, and 8+ in a Mac Pro. Wait a year then refresh all those platforms by doubling the number of cores with no change in software.

Moving to its own microprocessors would maintain Windows compatibility (though possibly at some lower performance level), cut hardware costs by $200 or so, and make it that much harder for others to build Mac clones in the future.

And what about the jump to 1080p video distribution on iTunes? That will require faster hardware, especially on the Apple TV, which really needs a refresh. It would have been nice to introduce all of this for Christmas, but I'm not surprised it slid. And maybe January MacWorld is better, anyway, if Apple can also introduce new Mac Pros for content creation and those rumored giant Apple displays (HDTVs) with their built-in Apple TVs.

Cool Threads

A couple of columns ago we touched on the practical rebirth of parallel computing. In case you missed that column (it's in this week's links), the short version is that Moore's Law is letting us down a bit when it comes to the traditional way of increasing the power of microprocessors, which is by raising clock speeds. We've hiked them to the point where processors are so small and running so hot that they are in danger of literally melting. Forget about higher clock speeds then; instead we'll just pack two or four or 1000 processor cores into the same can, running them in parallel at slower speeds. Instantly we can jump back onto the Moore's Law performance curve, except our software generally doesn't take advantage of this because most programs were written for single cores. So we looked back at the lessons of parallel supercomputers, circa 1985, and how some of today's software applies those lessons, such as avoiding dependencies and race conditions.

But we didn't really talk much in that column about the use of threads, which are individual processes spun off by the main CPU. Each time the microprocessor adds a new task, it creates a thread for that task. If the threads are running on the same processor they are multiplexed using time-slicing and only appear to run in parallel. But if the threads are assigned to different processors or different cores they can run truly in parallel, which can potentially get a lot of work done in a short amount of time.

Most traditional PC applications are single-threaded, meaning the only way to make them go faster without a completely new architecture is to run the CPU at a faster clock rate. Single-threaded apps are simpler in that they are immune to the dependencies and race conditions that can plague true parallel code. But they are also totally dependent on tasks being completed in a quite specific order, so in that sense they can be dramatically slower or dramatically more resource-intensive than multi-threaded apps.

For an example of where single-threaded applications are just plain slower, consider Eudora, which is still my favorite e-mail client (I'm old, you don't have to tell me). Until not very long ago Eudora still couldn't send mail in background, so everything (and everyone, including the user -- me) had to wait until the mail was sent before completing anything else, like writing a new message or replying to an old one. I KNOW THIS IS NO LONGER THE CASE, SMARTY-PANTS -- THIS IS JUST AN EXAMPLE. The program was single-threaded and, since sending mail is a very slow activity, users were generally aware that they were waiting. Today Eudora sends mail in background, which is the same as saying "in another thread."

Multithreading has been great for user interactivity because nothing should ever stop the input of data from typing, mouse movements, etc.

There are many ways to use threads and before we consider some let's think about scale -- literally how many threads are we talking about? To run at true clock speed we'd have only one thread per CPU core, but a fast processor can multiplex hundreds or even thousands of threads and multi-core processors can do even more. So the EFFICIENT shift to multi-threaded programming requires a significant change in thinking on the part of developers.

Here's an example: A hard problem with programming games is when you want something to happen every so often. That's not very efficient to code because it traditionally requires a program loop that spins as fast as the CPU will let it (making the CPU go to 100 percent) and keeps checking the time to see if it is time to do that thing. But threads are different: With threads you can very easily put them to sleep for any period of time, or even put them to sleep indefinitely until some event occurs. It's not only easier for the programmer, it takes nearly no CPU power compared to the looping system.

How do you use threads to write an e-mail server that handles thousands of simultaneous incoming e-mails? Well, you write it as if you were writing a server that can only handle ONE e-mail at a time. Just write very simple code that knows how to accept e-mail, then test it by sending in an e-mail. It works? Cool. Now send 1000 threads into that same piece of code. Each thread has its own state as to what e-mail (FROM, TO, SUBJECT, etc.) it is receiving, but despite the fact that that the content is different, the process is exactly the same. Now you have an e-mail server capable of serving a thousand simultaneous connections.

See, writing multi-threaded apps may require a different approach but the benefits from doing so can be fantastic.

A new area of multi-threaded programming that is REALLY hard (hard even for developers who do normal multi-threaded programming really well) is the use of optimistic concurrency. Two columns ago I alluded to this in my example of Appistry's decision to forego using a database for a credit card processing application. I said I would show a hack that was yet another approach to the same problem. Well here comes the hack.

Let's consider this problem: My wife (the young and lovely Mary Alyce) and I happen to be in different parts of town, each of us standing in front of a bank ATM machine. I am a thread, Mary Alyce is a thread, and the ATM is main memory. Contrary to our usual behavior in which we only take money OUT of the bank, we are paradoxically planning near-simultaneous bank deposits. Our balance starts at $1000. I am depositing $200 while Mary Alyce is depositing $300.

The ATM does the process like this:

1. Retrieve existing balance
2. Add new deposit to that balance
3. Update new total balance

The trick is that we are both doing this same thing at the same time. What if this happens:

Bob starts deposit transaction
Mary Alyce starts deposit transaction
Bob's ATM grabs the balance ($1000)
Mary Alyce's ATM grabs the balance ($1000)
Bob deposits $200 (his ATM updates the balance to $1200)
Mary Alyce deposits $300 (her ATM updates the balance to $1300)
Bob's ATM updates the main database with the new balance ($1200)
Mary Alyce's ATM updates the main database with the new balance ($1300)

This is a race condition. Mary Alyce updated the balance last so my deposit is lost completely. There are many ways for this to work out still, but also many ways for it not to work out OK. And any traditional solution requires a LOT of back-end reconciliation and computation. We need something simpler.

Classic concurrency control would basically LOCK the database. This is called, not surprisingly, "pessimistic concurrency." So I go up to the ATM and my ATM requests the database to be locked for me. If Mary Alyce then went to another ATM it would tell her she has to wait because the database was being updated elsewhere. This ensures that the race condition can't happen, but it also holds up Mary Alyce, who does not like to be kept waiting.

Optimistic concurrency control says, "We KNOW there could be a race condition, but we'll add a very cheap way to detect if it occurred. And if so, we'll pay the very expensive cost of restarting one of the transactions from the beginning."

The only changes from the above sequence are in the last two lines:

Bob's ATM updates the main database with the new balance ($1200)
Mary Alyce's ATM updates the main database with the new balance ($1300)

These become:

Bob's ATM updates the main database with the new balance ($1200) so long as the current balance is still $1000.
Mary Alyce's ATM updates the main database with the new balance ($1300) so long as the current balance is still $1000.

That's easy to write but trickier to implement. The check of the balance and the update of the new balance must occur within the microprocessor as an atomic action. It all must happen basically as one single operation. Some processors have had these instructions for a long time, but they're pretty common now and called "test-and-set" or "compare-and-set" instructions.

If the "so long as" part fails, the whole transaction must be restarted from scratch. In our example, Mary Alyce's $300 would pop back out of the machine and she'd have to start over.

That's very expensive for Mary Alyce, but the actual occurrence of the race condition is very rare. So although the redo is expensive it hardly ever happens, so no one has to wait for another person doing an update operation.

Apply this to 25,000 ATMs and suddenly the database is decoupled from transaction processing and the system is additionally controlled for internal race conditions such that it can run with less code and at full speed, which is saying something. Suddenly the system can be 100 times faster (cascading 10X improvements) or run 10 times faster on one tenth the hardware (take your pick), all thanks to the timely embrace of clever multi-threaded programming.