[HN Gopher] Atomic polling intervals for highly concurrent workl...
       ___________________________________________________________________
        
       Atomic polling intervals for highly concurrent workloads
        
       Author : mmastrac
       Score  : 8 points
       Date   : 2024-06-02 19:54 UTC (3 hours ago)
        
 (HTM) web link (www.byronwasti.com)
 (TXT) w3m dump (www.byronwasti.com)
        
       | forrestthewoods wrote:
       | If you're mutating the same atomic across 100 threads you're
       | gonna have a bad time. Atomic doesn't mean fast. Hell, that might
       | even be slower than using a mutex? Despite what you'd hope,
       | atomic doesn't mean fast.
        
         | jeffbee wrote:
         | Indeed, the article is quite misleading by supposing that
         | atomic variables are magic at the hardware level. On some
         | hardware yes, on others no. As an example the original AWS
         | Graviton is vanilla armv8-a without atomics, so atomic concepts
         | in languages are simulated with retry loops having unbounded
         | latency. Your thread that wants to increment an atomic may be
         | blocked literally forever if there are enough contenders for
         | that cache line. Library mutex implementations are usually
         | hybrids with limited atomic spinlocks, with pauses or sleeps,
         | then fallbacks to heavyweight synchronization with fairness
         | features such as futex. On certain Intel hardware we also have
         | lightweight userspace notification when a given address has
         | been written. That can be used for adaptive wakeup on atomic
         | values but it is "lightweight" relative to futex, since it
         | still requires a rdtsc and still amounts to an efficient
         | spinloop. On Intel Atom CPUs you can do this with up to 4
         | threads for free, but 100 threads will still be a mess.
        
       ___________________________________________________________________
       (page generated 2024-06-02 23:00 UTC)