3 ms·

All I have to do is give up all hope of my code ever being portable to multiple architectures You know nothing about modern compiler atomics. Post 2011 co

All I have to do is give up all hope of my code ever being portable to multiple architectures You know nothing about modern compiler atomics. Post 2011 compilers (LLVM, GCC, MSVC, ICC) standardized generic memory fences for C++ and C. These are fully portable as the compiler itself determines how the layout of Acquire/Releases needs to be changed on platform you are compiling too. Atomics are supported on ARM, x64, MIPS64, SPARC64, POWER8, POWER9... So they're very portable. The compiler even manages removing unneeded fences. Like if you add an acquire fence after a CAS load. The CAS load is an acquire fence on x64, but not on POWER8.

qwertyuiop924 10y ago
Okay, what about HLLs? Memory fences don't work if you aren't writing C. And as I've said, forks are an easier way to get these guarantees, albeit at a moderate perf cost.
- valarauca1 10y ago
  Seeing as this a conversation thread about raw system calls I assume we were working C not a HLL. Are you just a professional contrarian? Why are you concerned about system calls in a HLL? Why are you concerned with concurrency guarantees in a HLL? You care about none of these, you care about your run time. This is why you are working in a HLL.
  - deleted 10y ago
    [deleted]
  - qwertyuiop924 10y ago
    Are you just a professional contrarian? No. Why are you concerned about system calls in a HLL? Because in many HLLs, fork(2) is the best (or sometimes the only) option for concurrency. As in C, it is certainly the simplest. Many things written in HLLs use fork. Unicorn is perhaps the most famous example. Why are you concerned with concurrency guarantees in a HLL? Because if I have multiple threads of execution, I want them to run in parallel if possible, and I want to minimize the risk of deadlocks. fork(2) does both. You care about none of these, you care about your run time. This is why you are working in a HLL. No. I care about them, as demonstrated above. And I don't know what you mean by care about my runtime. I would go so far as to claim that the above is an insult to me and everybody else who uses an HLL. I care about getting stuff done. If C is the right tool for that, I'll use it. If an HLL is the right tool, I'll use it. And if syscalls are the right tool for the job, I'll use them, too.

qwertyuiop924 10y ago

Okay, what about HLLs? Memory fences don't work if you aren't writing C. And as I've said, forks are an easier way to get these guarantees, albeit at a moderate perf cost.

valarauca1 10y ago
Seeing as this a conversation thread about raw system calls I assume we were working C not a HLL. Are you just a professional contrarian? Why are you concerned about system calls in a HLL? Why are you concerned with concurrency guarantees in a HLL? You care about none of these, you care about your run time. This is why you are working in a HLL.
- deleted 10y ago
  [deleted]
- qwertyuiop924 10y ago
  Are you just a professional contrarian? No. Why are you concerned about system calls in a HLL? Because in many HLLs, fork(2) is the best (or sometimes the only) option for concurrency. As in C, it is certainly the simplest. Many things written in HLLs use fork. Unicorn is perhaps the most famous example. Why are you concerned with concurrency guarantees in a HLL? Because if I have multiple threads of execution, I want them to run in parallel if possible, and I want to minimize the risk of deadlocks. fork(2) does both. You care about none of these, you care about your run time. This is why you are working in a HLL. No. I care about them, as demonstrated above. And I don't know what you mean by care about my runtime. I would go so far as to claim that the above is an insult to me and everybody else who uses an HLL. I care about getting stuff done. If C is the right tool for that, I'll use it. If an HLL is the right tool, I'll use it. And if syscalls are the right tool for the job, I'll use them, too.