By Ashley Hedberg, Software Engineer
The C++ Standard provides a library for performing fine-grained atomic
std::atomic). Engineers sometimes reach for these
atomic operations in the hope to introduce some lock-free mechanism,
or to introduce clever tricks to improve performance. At Google, we’ve
found – more often than not – that such attempts lead to code that
is difficult to get right, hard to understand, and can often introduce
subtle and sometimes dangerous bugs.
We’ve now published a guide on the danger of these atomic operations, and are publishing it to Abseil as a general programming guide. Atomic operations should be used only in a handful of low-level data structures which are written by a few experts and then reviewed and tested thoroughly. Most programmers make mistakes when they attempt direct use of atomic operations. Even when they don’t, the resulting code is hard for others to maintain.
For more information, check out The Danger of Atomic Operations.
We’re very pleased to announce that the “Software Engineering at Google” book (the Flamingo Book) is now freely available electronically under a Creative Commons license. You can get a PDF at SWE Book.
From the very beginning of this project, about three years ago, our intent has been to describe how Google thinks about Software Engineering, and to get people thinking about the same kinds of big interesting problems. We think that the best way to do that is to make sure that the content is available for everyone, so we’re providing it now, free of charge. We’re very grateful for our partners at O’Reilly for helping to make this possible (and of course we encourage you to support them and buy a physical copy if you can, etc).
Some of you may be aiming to land a job at Google in the future: we’ve heard from dozens of Nooglers that this is the handbook they needed to understand the unique and complex machine that is Google. We hope this book is useful for you.
Some of you may be running your own software companies. You’ll have different scales and problems, but hopefully you can learn from how we think about problems arising from Time and Scale, and how we evaluate the relevant Tradeoffs (these are the main themes threaded through every chapter of the book). You may want to lean on our thinking, or blaze your own trails. We hope the insights we’ve earned the hard way can make your path easier.
Some of you may know more than us. There are several topics in the book where we are still trying to find a good answer. We’re making our thinking public - why not show us where we’re wrong?
Over the past year we’ve heard from hundreds of you, all over the world, with stories about how this material has affected your practice and thinking. We’re also seeing this picked up by colleges and universities looking to modernize their discussion of software engineering topics. We’re thrilled at this reception, and very excited that we can take this next step in sharing this material.
As Nicole Forsgren told us once, “Accountants still have meetings to discuss their practices, and accountancy goes back thousands of years. Software Engineering is barely 50 years old. Give us a minute.” As an industry, and as a discipline, we’re still figuring things out. We hope that this book, in some small way, can help with that.
-Titus, Tom, and Hyrum
By Derek Mauro, Abseil Engineer
We will support our code for at least 5 years. We will support language
versions, compilers, platforms, and workarounds as needed for 5 years after
their replacement is available, when possible. If it is technically infeasible
(such as support for MSVC before 2015, which has limited C++11 functionality),
those will be noted specifically. After 5 years we will stop support and may
ABSL_HAVE_THREAD_LOCAL is a good example: the base
language feature works on everything except Xcode prior to Xcode 8 ; once
Xcode 8 is out for 5 years, we will drop that workaround support.
By Xiaoyi Zhang, Google Engineer, Emeritus
The Abseil status library is now available on abseil.io. This library is used within Google for error handling and contains the following two abstractions:
absl::Status is the primary mechanism to gracefully handle
errors across API boundaries (and in particular across RPC boundaries). Some of
these errors may be recoverable, but others may not. Most functions that can
produce a recoverable error should be designed to return either an
absl::Status (or the similar
absl::StatusOr<T>, which holds either an object
T or an error).
By Chris Kennelly, Google Software Engineer
We are happy to announce the arrival of TCMalloc, a fast memory allocator with useful profiling and introspection features.
The source code can be found on Github. This is a distinct repository, allowing Abseil to be used independently of TCMalloc. The library includes: