HackerTube.dev

Advanced Topics in Programming Languages: A Lock-Free Hash Table

GoogleTalksArchive · 29.1K views · 2012-08-22 · 58:36

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

A 2007 Google Tech Talk in which Cliff Click of Azul Systems presents a lock-free concurrent hash table that scales to 768 CPUs. He explains why it is correct by reasoning in a different way than usual happens-before and memory-order arguments.

On Hacker News

HN regards it as one of the best technical talks, a deep and clear walkthrough of scalable lock-free hash tables built on compare-and-swap.

Recommended by 4 HN people across 5 months · HN mentions 2013–2024

Topics

Search by tags

What people said

benreesman · 2024-09 · Strong recommendation

For folks interested in this topic I highly recommend this talk by Cliff Click about building highly scalable hash tables via Compare And Swap: [VIDEO]

Read the original HN comment ↗
qznc · 2013-04 · Strong recommendation

Probably this one: [VIDEO] Anything from Cliff Click is quite good. This guy has a very deep understanding of compilers, virtual-machines, CPUs, and their interactions. A JVM does that? [LINK] Java on a 1000 Cores [LINK]

Read the original HN comment ↗
benreesman · 2022-08 · Recommendation

It's worth noting that for a lot of people for a long time, Intel TSO was the memory model in practice (which IIRC makes `std::memory_order_seq_cst` pretty much free on Intel). Many clothes have been torn and many teeth gnashed porting C++ from Intel to more relaxed architectures. Back in the day that usually meant like SPARC, today that usually means ARM. "Acquire" and "Release" are relatively comprehensible in isolated examples, but the intuitions don't compose well. It's realllly easy to end up with an ABA type issue or an architecture dependency even with the simplest lock-free primitives like CAS. Combine that with how cheap `std::mutex` is on most platforms and it's just really a last resort, at least on server-class gear. Google engineers have more experience with this than probably anyone, and they've summed it up nicely here: [LINK] . Doing raw atomics isn't quite "roll your own cryptography", but it's clearly in "if you have to ask, don't use it" territory. I've lost count of how many times I've fuzzed something to Mars and back to show it "correct" and not been able to justify it compared to `pthread` when the profiles were in. With that disclaimer, people are going to do it, and so I should probably leave an example of it done well: [VIDEO]

Read the original HN comment ↗

Sources

Video by GoogleTalksArchive, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources