Make _swift_willThrow atomic

[grynspan]

This change makes _swift_willThrow a C++ atomic value instead of a bare pointer. This change is necessary because the pointer can be loaded across multiple threads concurrently.

Resolves #62348.

[grynspan]

@swift-ci please test

[grynspan]

@swift-ci please test

[grynspan]

@swift-ci please test

[grynspan]

@swift-ci please test

[al45tair]

LGTM.

Makes me wonder whether we do this for other callbacks, or whether we're relying on callers using them before going multithreaded or inserting their own barriers as appropriate.

[mikeash]

We have hooks for retain/release and for the default global executor. THey're all implicitly relying on being set before multithreaded access happens. Retain/release is in practice set early in a static initializer inserted with DYLD_INSERT_LIBRARIES. The global executor hooks are up to whatever might use them, there's no specific use case there. We should probably standardize everything on something sensible like this.

[grynspan]

We have hooks for retain/release and for the default global executor. THey're all implicitly relying on being set before multithreaded access happens. Retain/release is in practice set early in a static initializer inserted with DYLD_INSERT_LIBRARIES. The global executor hooks are up to whatever might use them, there's no specific use case there. We should probably standardize everything on something sensible like this.

The difference with this callback is, I think, that it's known that we set it late in execution, in another module, after other threads or tasks have already been spun up. That's why I opted to change it. I don't personally want to go around messing with those other callbacks unless somebody can show an example of them being set later in execution.

[grynspan]

FWIW the overhead of making the global executor hook atomic is going to be negligible, so if it can be set late or arbitrarily, I'd agree we should take steps to make it safer.

I wouldn't dare say the overhead is negligible for retain/release, though.