Concurrency: Factor atomic operations in Task.sleep() into a Sendable wrapper

[tshortli]

When building the Swift standard library, the compiler warns:

warning: capture of 'wordPtr' with non-sendable type 'UnsafeMutablePointer<Builtin.Word>' in a `@Sendable` closure

This diagnostic will become an error in the Swift 6 language mode, so it needs to be addressed. This PR factors the atomic operations used by the implementation of Task.sleep() into an @unchecked Sendable wrapper in order to convince the compiler that these operations are thread-safe. As an added benefit, the code is more readable when the atomic operations are abstracted away. This refactor intentionally translates the existing implementation into a wrapper as faithfully as possible and does not attempt to improve on any other aspects of the implementation, such as the unsafe manual memory allocation and deallocation.

[tshortli]

@swift-ci please test

[Azoy]

I wonder if we can use Atomic here? Would require making some things noncopyable, but it should be fine? I haven't taken look to see if we'd eventually end up in some ABI type (I stopped at SleepState which is non-ABI). Alternatively, we're close to having pointers to noncopyable types so we could say UnsafeMutablePointer<Atomic<Int>> soon. (Why is this using Builtin.Word instead of Int?)

[tshortli]

I wonder if we can use Atomic here? Would require making some things noncopyable, but it should be fine? I haven't taken look to see if we'd eventually end up in some ABI type (I stopped at SleepState which is non-ABI). Alternatively, we're close to having pointers to noncopyable types so we could say UnsafeMutablePointer<Atomic<Int>> soon.

When working on this I did briefly try to explore whether it was possible to use a non-copyable type to entirely replace the need for a pointer to heap allocated storage. However, as far as I can tell there'd be no way to convince the compiler that the lifetime of the closure passed to Builtin.createAsyncTask that captures the "token" does not exceed the lifetime of a value stored on the current task's stack because that closure is necessarily @escaping.

If adding a dependency on Synchronization to _Concurrency is okay, then preferring UnsafeMutablePointer<Atomic<Int>> over using built-ins seems reasonable to me. Everything changed in this PR is an implementation detail and shouldn't affect ABI. That said, I don't want to block the progress this PR makes on improving what's there today, so if we can't adopt Atomic quite yet then I'd prefer to get a reasonable version of this that's a low-risk adaptation of the original code landed. We can follow up to replace the use of UnsafeMutablePointer<Builtin.Word> and the built-ins in a subsequent PR.

(Why is this using Builtin.Word instead of Int?)

To match the expectations of the existing builtins used for atomic operations.

[tshortli]

When working on this I did briefly try to explore whether it was possible to use a non-copyable type to entirely replace the need for a pointer to heap allocated storage. However, as far as I can tell there'd be no way to convince the compiler that the lifetime of the closure passed to Builtin.createAsyncTask that captures the "token" does not exceed the lifetime of a value stored on the current task's stack because that closure is necessarily @escaping.

Ok, after looking into more I think this should be doable by using withoutActuallyEscaping. I'm going to try to implement a version of this with Atomic and open that as a PR stacked on this one so we can consider it separately.

[tshortli]

@Azoy I created a draft prototype of adopting Atomic instead here. As it turns out it works quite well, though I admittedly don't understand how the compiler is managing the lifetime of the Atomic state relative to the escaping closures which borrow it. The main blocker is that Atomic does not yet have real availability, so we can't actually use it yet in the implementation of _Concurrency.

[ktoso]

late to the party here -- I was looking into this recently and it turned out we didn't properly handle nonisolated(unsafe) for local variables (heh). That was fixed since then so I wondered if we could just nonisolated(unsafe) the wordPtr now and avoid the wrapper entirely.

Although avoiding the alloc entirely would be even better...! So thanks for investigating that too.

[ktoso]

This resolved rdar://117594245