The Concurrency runtime code is all in stdlib/public/Concurrency.
I would have thought std::atomic would work for us here.
I don't think we will want locking in the hot path here; the danger is that adding locks in the wrong place will cause all concurrent code to have to funnel through a single lock, unintentionally serialising it to some degree. And we don't want that.
I have an idea or two, but I don't want to share that up front because if this proposal runs, I would like the person working on it to think about it themselves — maybe you will turn out to have a better idea in mind than the one I've been pondering. And maybe not, but I think part of this project is to investigate potential data structures and see which ones might work best.
I wouldn't start working on it yet. The thing we need at this stage is a proposal. Don't forget that (a) Google may not allocate a GSoC slot for this project, and (b) even if they do, it's possible multiple people are interested and so your proposal might not be chosen.
I suspect this is going to have to be done in C++ because of the atomics, but it's worth pondering whether we can in fact do it on the Swift side instead.
I'd also suggest being cautious about thinking you could use thread-local or per-executor storage here to somehow avoid locking. The problem with that is that a Task can be scheduled and re-scheduled, and end on a different thread to the one it started out on. Similarly with executors.
Absolutely, and the same applies to anyone else interested.