4 ms·

Fork/Exec is only good if you are going to run a different program then you are currently executing. If you want a series of worker threads that are effectivel

Fork/Exec is only good if you are going to run a different program then you are currently executing. If you want a series of worker threads that are effectively the same as the master/initial thread. The proper way to do this clone(2) not fork, or fork/exec. When used properly clone allows your group of threads to share a single PID, and TGID (Thread Group IDentifier). This cuts down on kernel resources your process(es) are using. They can natively share file descriptors and memory between each other (improving cache coherence). Also their signals are handled globally for all threads at once, not each thread managing it's own signals like Fork/Exec will result in.

stsp 10y ago
$ man 2 clone man: No entry for clone in the manual.
qwertyuiop924 10y ago
...And why would you want that? The advantage for fork(2) over clone is that you CAN'T share those datastructures, making it harder to write code resulting a deadlock: you have to share explicitely. As for the kernel resources for the process, you'd be surprised how large RAM has gotten these days...
- valarauca1 10y ago
  ...And why would you want that? All your applications share the same virtual memory space. So you have a much higher hit rate in your TLB, then without. It greatly lowers the chance that shared memory will leave L3 cache. Cache hit rates are very important... The advantage for fork(2) over clone is that you CAN'T share those datastructures, making it harder to write code resulting a deadlock Dead locking has nothing to do with how RAM is accessed or how virtual memory is partitioned, it has to do with how you are managing your locking. Modern memory/instruction re-ordering is stupidly fast. If you are locking memory/data structure locations you are likely doing something wrong. Concurrent Memory fences are around 3 orders of magnitude faster then locks. As for the kernel resources for the process, you'd be surprised how large RAM has gotten these days... TLB/L2/L3 cache is still premium real-estate. RAM size is awesome! I love waiting 100,000cycles to get the page I requested.
  - qwertyuiop924 10y ago
    Cache hit rates aren't as important as you seem to think. If you're not google, and your app doesn't have hard/soft realtime constraints (videogames, flight control systems, etc.) your app will probably be fast enough. You'd be surprised how fast computers are nowadays... >If you are locking memory/data structure locations you are likely doing something wrong. Oh, concurrent memory fences! Well, that solves all my problems. Let's see. All I have to do is give up all hope of my code ever being portable to mutiple architectures, and than dig around in asm to add support for them to my environment, which can range from mildly annoying (C), to near-impossible (JVM). Or I can use fork(2), and do what programmers have been doing for decades: trading performance for simplicity, and productivity. That'll be a really hard decision.
    - valarauca1 10y ago
      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.

stsp 10y ago

$ man 2 clone man: No entry for clone in the manual.

qwertyuiop924 10y ago

...And why would you want that? The advantage for fork(2) over clone is that you CAN'T share those datastructures, making it harder to write code resulting a deadlock: you have to share explicitely. As for the kernel resources for the process, you'd be surprised how large RAM has gotten these days...

valarauca1 10y ago
...And why would you want that? All your applications share the same virtual memory space. So you have a much higher hit rate in your TLB, then without. It greatly lowers the chance that shared memory will leave L3 cache. Cache hit rates are very important... The advantage for fork(2) over clone is that you CAN'T share those datastructures, making it harder to write code resulting a deadlock Dead locking has nothing to do with how RAM is accessed or how virtual memory is partitioned, it has to do with how you are managing your locking. Modern memory/instruction re-ordering is stupidly fast. If you are locking memory/data structure locations you are likely doing something wrong. Concurrent Memory fences are around 3 orders of magnitude faster then locks. As for the kernel resources for the process, you'd be surprised how large RAM has gotten these days... TLB/L2/L3 cache is still premium real-estate. RAM size is awesome! I love waiting 100,000cycles to get the page I requested.
- qwertyuiop924 10y ago
  Cache hit rates aren't as important as you seem to think. If you're not google, and your app doesn't have hard/soft realtime constraints (videogames, flight control systems, etc.) your app will probably be fast enough. You'd be surprised how fast computers are nowadays... >If you are locking memory/data structure locations you are likely doing something wrong. Oh, concurrent memory fences! Well, that solves all my problems. Let's see. All I have to do is give up all hope of my code ever being portable to mutiple architectures, and than dig around in asm to add support for them to my environment, which can range from mildly annoying (C), to near-impossible (JVM). Or I can use fork(2), and do what programmers have been doing for decades: trading performance for simplicity, and productivity. That'll be a really hard decision.
  - valarauca1 10y ago
    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.