@synchronized swimming

Monday, October 30, 2006 at 6:20 PM

Posted by: Dave MacLachlan, Member of Technical Staff, Mac Team

(Editor's note: today's post is a bit different from our usual fare -- it's aimed at the Mac programmers out there. And if you're not a programmer, you might want to find one to guide you through this peek behind the scenes of how we make our applications fast and reliable.)

At Google, software performance is extremely important. Every millisecond counts, which is why we spend a lot of time using performance tools and other techniques to help make our software faster. I was recently Sharking a piece of multithreaded code and realized we were getting bitten by the use of an @synchronized block around a shared resource we were using:

+(id)fooFerBar:(id)bar {
@synchronized(self) {
static NSDictionary *foo = nil;
if (!foo) foo = [NSDictionary dictionaryWithObjects:...];
return [foo objectWithKey:bar];

Shark told us without a doubt that we were paying heavily for the @synchronized block each of the millions of times we were calling fooFerBar. We couldn't create the resource in +initialize, because fooFerBar was part of a category, and overriding +initialize in a category is a bad thing. We also couldn't use +load, because other classes could have easily called fooFerBar in their +load, and there's no guarantee on loading order. So our only choice was to minimize the impact of that @synchronized block, and we didn't want to run into the infamous and dreaded double-checked locking anti-pattern.

So, I wondered, how exactly does @synchronized work? And is there a cheaper way of getting the same thread-safe result? I disassembled the code to find out what @synchronized does, and I saw something like this:


my actual code


That's a lot of setup and tear-down for a simple lock around a shared resource. In this case, we don't need to be exception safe. By reading the Objective-C documentation on exception handling and thread synchronization, we learn that not only does @synchronized give us a lock, but it's a recursive lock, which is overkill for this particular usage.

By examining the code (ADC registration required) that implements objc_sync_enter and obc_sync_exit, we can see that on every @synchronized(foo) block, we are actually paying for 3 lock/unlock sequences. objc_sync_enter calls id2data, which is responsible for getting the lock associated with foo, and then locks it. objc_sync_exit also calls id2data to get the lock associated with foo, and then unlocks it. And, id2data must lock/unlock its own internal data structures so that it can safely get the lock associated with foo, so we pay for that on each call as well.

We need to do better than this. It looks like it's time to go back to basics, throw away the @synchronized call, and wrap our code with some pthread locks instead.

#include <pthread.h>

+(id)fooFerBar:(id)bar {
static pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
if (pthread_mutex_lock(&mtx)) {
printf("lock failed sigh...");
static NSDictionary *foo = nil;
if (!foo) foo = [NSDictionary dictionaryWithObjects:...];
if (pthread_mutex_unlock(&mtx) != 0)) {
printf("unlock failed sigh...");
return [foo objectWithKey:bar];

This is ugly stuff, but it's significantly faster, according to Shark. And fast is what we want. We've avoided setting up an exception stack, two excess locks, and a bunch of miscellaneous support code.

So we've achieved our goal of faster code that will work fine, but are there other, cleaner options? After all, if the code is cleaner, there are fewer places for bugs to hide. Tune in for our next post, wherein we'll explore that question.

Google goes to MacExpo UK

Monday, October 23, 2006 at 9:09 PM

Posted by: Tim Partridge, Associate Product Marketing Manager, UK

As a Mac fanatic for over fourteen years, I was thrilled to find my first job here at Google UK would be working on Google’s presence at this year’s London MacExpo UK.

People here recognise the passion that Mac users have for their computers, and we really want to show you all the great things you can do when you use Google products in your projects. As Jason Chuck, one of our European product marketing managers said, "Google and Apple users could really have a fruitful relationship." (He wanted to put that on a t-shirt, but we wouldn’t let him.)

And so this Thursday, we’re taking Google for Macs on the road to the Olympia Exhibition Centre, bad puns and all. We’ll be there for all three days, MacBooks in hand, to show you how to get the most from Google on your Mac. As well as being there to answer any questions you might have, we’ll be running five free workshops each day.

Each morning our Google Video session will highlight uploading videos and placing them within your site. Learn how to share your work with millions this way, and how to enliven your site with embedded videos. Following this, find out how to embed Google Maps into your own web pages, providing a useful way of displaying local information. We'll highlight some innovative examples of Google Maps mashups already online, and show how they were created.

From exotic locales to local restaurants and schools, Google Earth puts a planet's worth of imagery and other geographical information right on your desktop. In the afternoon we'll show how you can use Google Earth to display your own content using overlays. We will also showcase SketchUp, our award-winning 3D design software, demonstrating its simple yet robust toolset and how it too can be integrated with Google Earth.

If that's not good enough, there might even be a give-away or two. The exhibition kicks off on Thursday 26th October at 10am, and runs until Saturday 28th October. Tickets are available on the door, or by visiting the MacExpo website.

Our far-flung Mac team

Posted by: Greg Robbins, Software Engineer

Eight years ago, I moved from Silicon Valley to Seattle, leaving the heart of the Mac software development world for a vibrant city surrounded by tall mountains. I thought this meant that most of the interesting opportunities to be a Mac developer were left behind as well. But then a year ago, friends from Google mentioned that Google wanted to devote more attention to writing Mac software. More importantly, there was an office near Seattle set up for engineering (one of many), because Google knew that not all the best developers wanted to move to Mountain View. When I met some of the developers, I was happy to see Google's unique work culture had survived the northward migration intact.

Today, our Seattle-area engineering office in Kirkland is growing rapidly. In the two years since the office opened, we've grown to more than 150, and Kirkland drives the development of an impressive list of software products, including Google Video and Google Talk. The range of projects and expertise among the Googlers here makes it a fascinating environment.

True, most of the Mac programmers are in the Mountain View office. But I'm in Washington State, while others are in New York and elsewhere on the east coast. Finding a way to effectively collaborate across 3,000 miles and 3 time zones has been an enjoyable challenge. We have state-of-the-art tools, like video conferencing and Writely. But our daily development discussions take place in an internal group chat room that we set up for Mac developers. It's become a 24-hour meeting room and watering hole, a forum for us to seek programming assistance, exchange Mac industry news, and speculate on the upcoming features in Mac OS X Leopard. In debating how to turn our strengths into unique and exciting Mac applications, we've become a tight-knit group of colleagues.

Though I had worked in large and small companies prior to joining Google, the rapid pace of development here still amazed me. Within weeks, I was helping the Mac developers working on Google Earth get it talking with Sketchup, making Google Video player keep itself up to date, and turning a photo uploader that had been an impressive, experimental 20% project into a polished, easy way for Mac users to take advantage of Picasa Web Albums. Of course, even more cool applications are underway.

While I've made many friends among the Seattle-area developers (and I love the food here, too), I feel like I'm part of a wider team of incredibly smart and experienced Mac developers with shared goals -- but diverse weather.

Something old, something new

Monday, October 16, 2006 at 11:32 AM

Posted by: Scott Knaster, Technical Writer, and Rose Yao, Mac Product Manager

Scott says: The first time I used a Mac was back in 1983, a few months before the first one shipped, when I was working at Apple. In those days, most computers made you use a command line pretty much all the time. The Mac was very different: it collected together a whole bunch of revolutionary ideas, most importantly a mouse and a graphical user interface featuring point & click. Like so many others, I was blown away by that first Mac. I've spent almost all my career since then working on Mac stuff, and even during those few years when I was involved with an, er, other operating system (sorry about that), I still had a Mac close at hand.

So when I joined Google last year, and found out the company was starting up a dedicated Mac software team, I had plenty of friends and contacts to call upon and try to recruit. The word got around the Mac community, and an interesting thing happened: the Google Mac team became a nice mix of very experienced Mac folks together with people who are newer to the platform who are attracted by Mac OS X, its Unix base, and the fact that the Mac is more powerful, popular, and shiny than it's ever been. People like Rose...

Rose says: I'm part of the something new. When I was offered the opportunity to work with the Mac client team here, I hadn't used a Mac since high school and I wasn't sure what the big deal was. Although having a UNIX terminal at my fingertips sounded very tempting. I've been using a PC for years and it was just an OS to me: it's got its problems, but it gets the job done. After I met some of the engineers on the team, and watched a few of those really great Mac commercials, I started to become intrigued. But it wasn't until I got my shiny new MacBook Pro that I truly understood why the Mac inspires so much dedication among its users. Everything just worked and the brighter screen made my days in front of a computer a lot more fun. Not to mention the built-in camera, or showing my mom how I just recorded our piano and singing sessions on my new Mac.

So I've learned, and am still learning, a lot from my team about the platform, the design philsophy, and the needs of a Mac user. The greatest part of my job is to combine Google's mission with Apple's to build great products that bridge the gap between the web and the desktop. One of the reasons we started this blog was to give you guys, Google users, the inside scoop on the Mac team here and our products. Another reason was to ask for your feedback and suggestions -- so please use this Google Group to talk to us, and thanks.

Google and your Mac

Monday, October 09, 2006 at 1:23 PM

If you sit down at your Mac, start up your browser, and search for "Google mission statement", this is what you'll see:

" Google's mission is to organize the world's information and make it universally accessible and useful."

We're pretty serious about that mission, including the "universally accessible" part. It means making products that everyone can use – including Mac users. We want to provide great products and services to the tens of millions of Mac users around the world, because it's the right thing to do, and because Mac users inside and outside Google demand it. That's why we've recruited some of the best, most passionate Mac people out there for a Mac Engineering team. You can already check out the first results of their efforts at www.google.com/mac :

In addition to these, you might have noticed some other Mac goodness showing up in Google products such as Safari support for Google Calendar , full Mac support for Google Video, and the Mac version of Google Earth. These upgrades are the result of more work by Google's Mac Engineering team and friends.

We're thrilled to have our Mac team in place, and they're just getting started. Watch this blog to keep up with the latest about everything Google is doing to support Mac users.