Adding some shared state to a TaskGroup without abandoning structured concurrency?

Using Swift
1

here’s a basic width-limited TaskGroup i am using to accept incoming HTTP connections via the new NIO async APIs.

//  In an extension to `TaskGroup` ...
var iterator:Inbound.AsyncIterator = inbound.makeAsyncIterator()

for _:Int in 0 ..< width
{
    guard
    let element:Inbound.Element = try await iterator.next()
    else
    {
        return
    }

    self.addTask { await body(element) }
}

for try await _:Void in self
{
    guard
    let element:Inbound.Element = try await iterator.next()
    else
    {
        return
    }

    self.addTask { await body(element) }
}

now, i need to bolt on an additional component - a whitelist periodically refreshed from googlebot.json.

if i go all-out and protect it with an actor, then every incoming request needs to await on the actor to become available. which feels suboptimal, because this is data that is rarely written-to and only from one concurrent context, whereas it is read frequently from many concurrent contexts.

what’s the best way to add some shared state to a TaskGroup without forcing readers to suspend? there is no requirement that the readers access ‘the’ most-recent version of the data, as long as it turns over eventually.

2

You basically have two options, either actors or locks. So that’s about it. Reader writer locks are sometimes a thing but not sure if worth it, as always with performance: measure and then chance and then measure again.

1 Like
3

could AtomicReference be a third alternative here?

1 Like
4

Sure. Depends what the state you’re managing is

5

Remember that modifying a shared Array variable is bad, but simply depending on CoW across threads/tasks is fine (and same for the other CoW collections). So maybe every task can just snapshot the latest state, and it’ll get updates regularly? Or if they’re long-running tasks, they can ask for updates when it’s convenient to do so.

3 Likes
7

sigh. why doesn’t Sendable work with ManagedBuffer? why???

import Atomics

extension HTTP
{
    public final
    class Whitelist:ManagedBuffer<Int, (UInt8, [IP.V6: KnownPeer])>
    {
    }
}
extension HTTP.Whitelist:AtomicReference, Sendable
{
}

'Sendable' class 'Whitelist' cannot inherit from another class
8

The compiler can’t know that you’ve implemented CoW safely. If you have, it’s correct to use @unchecked Sendable, just like Array itself.

1 Like
9

yeah, that’s what i ended up using. i’m now entangled in Ironing out `ManagedBuffer` API wrinkles - #20 by 3405691582 , so i don’t even know if this is the right move anymore.

if it’s not already obvious, all i’m really trying to achieve here is an immutable, concretely-typed [(UInt8, [IP.V6: KnownPeer])] array that also conforms to AtomicReference, since Array itself is a struct. the whitelist type itself has yet to grow additional stored arrays that would justify a third layer of indirection.

10

To be clear, my original idea was that you don’t need AtomicReference, but also you could make this AtomicReference with an immutable OnHeap box around your Array type and that would be fine too.

11

how do you suggest avoiding AtomicReference entirely? maybe i am not understanding what you mean by

12

This is what I meant, though you might not consider it good enough. (I am not very experienced with Swift-on-Server!)

You do have an actor, like you mentioned in the original post, but you don't have to wait on that actor for every subtask, and because the updates to the actor are throttled the access will usually be uncontended anyway. And if you have to share the actor on the read side, it's still okay because the accesses are still spread out. (Though it's too bad there aren't "reader-writer actors"…but reader-writer locks don't play nicely with priority donation.)

2 Likes
13

actually, that’s a really good idea, it had not occurred to me that the task group could read the value lazily. it’s a little weird that there are now two levels of propagation, but that’s not really important for slow-changing data like this.

1 Like