4 ms·

There is no reason that `getenv()` should ever lock -- it should always be lock-free. `putenv()`/`setenv()`/`unsetenv()` can lock, of course, since there's no

• kimixa 3y ago
  What are you trying to say using that example? The getenv() function shown calls initenv(), which can (clearly) take a lock?
  • cryptonector 3y ago
    One time. Also, I think that could be removed with some care.
    • kimixa 3y ago
      But it unconditionally calls a memory barrier, which is most of the cost of an un-contended futex-style lock already. And I'd be interested in your ideas on removing the lock - as I can't see any paths that don't change semantics (e.g. unconditionally doing the init work at process start time when you know there's not multiple threads, for example)
      • cryptonector 3y ago
        > a memory barrier, which is most of the cost of an un-contended futex-style lock already Yes, but it's not a lock. > unconditionally doing the init work at process start time when you know there's not multiple threads That's the most obvious fix, yes. I was thinking (but I've not checked yet) that when `my_environ` is not set up yet then `getenv()` can use `_environ` directly.