Maps are relatively simple data structures, at least when used in synchronous code. When we start building async systems, much of this falls apart. To stop stale updates and crashes and to maintain consistency, we either need to sacrifice accuracy or add a lock so that only one thread can access a resource at a time.
eBPF runs in the kernel, and eBPF programs are essentially a multitude of asynchronous hooks that are called whenever syscall are invoked, and they all communicate through maps. Writing eBPF programs would be a pain if we had to use locks for every single piece of communication with a map.
But thankfully for us, eBPF has already solved this. If two different hooks run concurrently and update the same map, there will be no buggy/stale writes, and again, all of this is async code. Though this applies only to cases where two hooks are updating different keys in the same map.
If you really want to update the same key at the same time, you can use a per-CPU map, which allocates one map per CPU, eliminating the need for atomic operations. If this doesn’t work, you can always use a spin lock: https://docs.ebpf.io/linux/helper-function/bpf_spin_lock/.
Now, all of this would be trivial if not for the fact that eBPF maps are fast, like really fast https://dl.acm.org/doi/10.1145/3749216, 3.9 ns for BPF_MAP_TYPE_ARRAY, 18.8 ns for BPF_MAP_TYPE_HASH, and 19.2 ns for BPF_MAP_TYPE_LRU_HASH, averaged over 100K measurements with a 4-byte key. eBPF can achieve speeds lower than the average Go map lookup, which is around 25 ns. All of this with map safety over asynchronous operations.
This all works because the eBPF VM and the kernel own the entire implementation, and it is heavily restricted. States in eBPF maps transition fully, so if a reader reads a map value while a writer is writing, they will either get the old or the new value.
This also means that, even if two async hooks update a map at the same time, the map will still not break. Instead, one of the values will be written first, and the other will be written second, overwriting the first.
eBPF certainly isn’t easy to write, but it’s way easier than having to do stuff like this, and hundreds of other perf and quality of life improvements by hand.