Hacker News Reader

Comment by anarazel | Hacker News Reader

The epoch based approach basically is on of the many variants of RCU (as e.g. used by the Linux kernel - thoroughly documented on lwn.net BTW).

It does mean that a stuck or killed process can cause rather noticeable pain. With a GC you usually have a upper bound of the amount of memory one stuck process can prevent from being reclaimed, not so with a generation based approach.

On the other hand it dies often voids concerns around ABA style problems.

View on HN

Oh, one more thing: often an approach based on hazard pointers allows to reduce the impact of a stick or slowed down process, without using a GC. And while stool protecting against ABA. Another good thing is that luckily the patent application around it was rejected.

A couple years ago I saw a 3.5x improvement migrating a lockfree skiplist from hazard pointers to epochs. The problem with hazard pointers is that they require memory barriers after every assignment, whereas epochs only require one at the start.

Hazard pointers aren't any better when it comes to stuck processes, right? If you aren't removing your nodes from the hazard pointer list, you're stopping reclamation just as with this algorithm.

The epoch algorithm strikes me as pretty much strictly better than hazard pointers.

HP is much more granular and a stuck thread does not inhibit system wide progress (yes, the slots won't be reclaimed but other entries will continue to be reclaimed).

Reply on news.ycombinator.com