Avoid using global Mutex variables

[nguyenhuy]

After 5c9815f, some Mutexes are used as global C++ variables which are loaded before main(). Since the Mutex constructor checks for unfair lock experiment, it triggers an experiment configuration load, and our app isn't ready to respond that early in the process.

[CLAassistant]

All committers have signed the CLA.

[ghost]

🚫 CI failed with log

[Adlai-Holler]

Huh, I was under the impression that these new's shouldn't be executed until the variable is accessed ("magic statics" in C11). Could you post the stack trace where they're running early?

[nguyenhuy]

Sure, here is the stack trace

[ghost]

🚫 CI failed with log

[nguyenhuy]

These are run by dlyd before main().

[ghost]

🚫 CI failed with log

[Adlai-Holler]

Oh, right, magic statics only work for function-local statics not global variables. How about instead, we move the static variables into the functions in which they're used? That'll make them lazily generated. Currently each one is only used in one function.

Performance will be better if we use dispatch_once than if we rely on lazy statics, so:

- (void)myMethod {
static ASDN::Mutex *cacheMutex;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
  cacheMutex = new ASDN::Mutex();
});

// is faster than

static auto *cacheMutex = new ASDN::Mutex();

// because the latter actually uses a global mutex around all accesses to all function-local statics.
}

[nguyenhuy]

@Adlai-Holler Good call. I updated the call sites to use dispatch_once. Mind taking another look?

because the latter actually uses a global mutex around all accesses to all function-local statics.

Ohh, good to know!

[Adlai-Holler]

lgtm!

[nguyenhuy]

Thanks for reviewing!

[appleguy]

Cool. We're pretty confident this will have the desired lifecycle ever during app teardown, right? As some of the comments mention, the original solution was put in after some tricky-to-debug crashes on suspend.

[nguyenhuy]

@appleguy The lifecycle was a problem because ASDN::Mutex used to be a struct. It should be fine now, and we haven't seen any crashes related to this change.