Thanks, this is very useful. Reading it I was wondering how applications typically exploit the asymmetric fence, I hope the article you linked help in that regard.
I did a POC afterwards. For linux it was a bit PITA since /proc text had to be parsed to track context switches w/ associated full MB. For Mac OS on the ppc also bit PITA since Apple tried to hide their unix api and some stuff involved calling the mach micro kernel.
I can't help myself digging into the referenced source code. The membarrier syscall can fail to allocate, returning ENOMEM. The way Folly calls it, the program would abort. Which I guess is a fair strategy but it's good to know when your synchronization primitive is actually SynchronizeOrCrash.
If this fails, your system is already hosed; program abort vs kernel lock up a few seconds later is probably immaterial. I think folly's choice to abort is a reasonable one.
This is a great article but it goes into a lot of detail that can be intimidating at first.
For me, the reading that made asymmetric fences "click" is this: https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-r...
It might be easier to read that first, as it also goes into practical applications, and then this one.
Thanks, this is very useful. Reading it I was wondering how applications typically exploit the asymmetric fence, I hope the article you linked help in that regard.
For hazard pointers it was proposed here https://groups.google.com/g/comp.programming.threads/c/XU6Bt...
I did a POC afterwards. For linux it was a bit PITA since /proc text had to be parsed to track context switches w/ associated full MB. For Mac OS on the ppc also bit PITA since Apple tried to hide their unix api and some stuff involved calling the mach micro kernel.
An informal proof of why memory barrierless hazard pointers can't have false negatives. https://drive.google.com/file/d/1zDrXDdJHQEYILlwUSILPfSSiVzM...
I also just added these to Julia for 1.14 (https://github.com/JuliaLang/julia/pull/60311).
I can't help myself digging into the referenced source code. The membarrier syscall can fail to allocate, returning ENOMEM. The way Folly calls it, the program would abort. Which I guess is a fair strategy but it's good to know when your synchronization primitive is actually SynchronizeOrCrash.
> The membarrier syscall can fail to allocate, returning ENOMEM.
This is mentioned in the source comment, but not documented in the membarrier(2) manual page.
https://elixir.bootlin.com/linux/v7.1.2/source/kernel/sched/...
In reality... what is it allocating?
https://elixir.bootlin.com/linux/v7.1.2/source/kernel/sched/...
Ok, so it needs to allocate a cpumask (tiny) under some usages.
Similar requirement in other sites, e.g.: https://elixir.bootlin.com/linux/v7.1.2/source/kernel/sched/...
Depending on kernel config (e.g., !CONFIG_CPUMAKS_OFFSTACK), this allocation literally cannot fail:
https://elixir.bootlin.com/linux/v7.1.2/source/include/linux...
On OFFSTACK configs, it's merely a tiny heap allocation:
https://elixir.bootlin.com/linux/v7.1.2/source/lib/cpumask.c...
If this fails, your system is already hosed; program abort vs kernel lock up a few seconds later is probably immaterial. I think folly's choice to abort is a reasonable one.
In Linux everything is XOrCrash, since allocations never fail but the OOM killer can get you later.
Claude, deal with this
[flagged]