5 ms·

That doesn't work because there's a race condition - if both processes increment the MAP_SHARED counter at the same time, they could end up seeing the same valu

• geocar 11y ago
  Use an atomic increment (e.g. lock xadd).
  • agwa 11y ago
    That's architecture-specific, which isn't nice. Also, the counters would need to be 64 bits so that wraparound isn't a concern. Do all architectures even have an atomic 64 bit increment?
    • geocar 11y ago
      What, and linux isn't architecture-specific? The counters don't need to be 64-bits: Programs don't need a random number in one process and the 4 billionth only.
      • agwa 11y ago
        > What, and linux isn't architecture-specific? I have no clue what point you're trying to make. > The counters don't need to be 64-bits: Programs don't need a random number in one process and the 4 billionth only. If this is going to be used for a CSPRNG, you have to take into account adversarial conditions. A 32 bit counter leaves insufficient safety margin: it's conceivable an attacker could induce an application to generate so many random numbers that the counter wraps around, causing another process to generate a duplicate random number. It may seem unlikely, but time after time security researchers have demonstrated that attacks previously considered "unlikely" are possible.
        • geocar 11y ago
          No, a 64-bit atomic add isn't required. Smaller atomic adds can be used just fine with a double-wide number.