[Concurrency] Actors & actor isolation

That example should be reliably optimized because there’s no significant code between two calls with known actor-independence. We may have to impose some high-level rules about when we can reasonably assume actor-independence, or else we’ll find ourselves completely blocked by theoretical actor dependencies like, say, a global function reading from actor-protected state somehow.

2 Likes

I don't know of a way to express it in this pitch's design so I'll modify the design a bit to demonstrate:

/// Instead of applying a global actor attribute such as `@UIActor` an actor conforms to this protocol
/// and specifies the global actor context using an associated type
protocol GlobalActor: Actor {
    associatedtype ActorContext
}

This change in the design allows me to express this:

final actor class Store<Value, Action, ActorContext>: GlobalActor { ... }

Instances of this type are bound to a global actor without knowing which global actor. As far as I can tell this is not possible with the current pitch for two reasons: you cannot constrain ActorContext to be an @globalActor and you cannot apply an @ActorContext to the Store class.

With this modification, we are also able to apply constraints on the ActorContext of a GlobalActor. For example, you could write code that is generic over another actor, but must have the same execution context as Self, or a concrete known execution context such as UIActorContext. The compiler could take advantage of this to allow synchronous access to synchronous API of actors from other actors in generic code (as long as they are constraints dot share the same ActorContext). I don't see any way to support this in the pitch as written. Here's an example:

struct SomeGenericView<A: ObservableObject>: View 
  where A: GlobalActor, A.ActorContext == UIActorContext 
{ 
   @ObservedObject let actor: A

   // The compiler would need to know this can only be called on main / UIActorContext.
   // I'm not sure how to express that...
   var body: some View {
      // sync access to members of the actor made available via additional constraints
   }
}
3 Likes

I think if we were going to allow this sort of actor-generics, it would need to support actor classes as well; can you figure out a way to make that work?

The Store in my example is an actor class so I don’t understand the question. Can you elaborate?

Another example from my library is:

final actor class TupleStore2<Store0: GlobalActor, Store1: GlobalActor>: GlobalActor
  where Store0.ActorContext == Store1.ActorContext
{
    typealias ActorContext = Store0.ActorContext
}

In my library TupleStore2 is actually a struct. Ideally a heap allocation could be avoided but I'm not sure how that could be expressed in terms of the current pitch.

If I understand correctly, you are trying to write generics that are generic over an actor. But it looks to me that in general you’re trying to just carry the actor as a type, which will only work for global actors.

I had an idea that didn’t make it into these pitches of an “actor accessory” type, which could have a let actor property that would dynamically specify the right actor. That approach seems to still allow the sort of static reasoning that you want while also being theoretically extensible to generics.

I don’t understand why Store itself is an actor in your example.

If we wanted to extend my design to support a unique queue per-instance like the default actor class I think we could do that like this:


/// Only `Never` conforms
protocol _ActorContext {}

/// User-defined global actor context types conform to this protocol:
protocol GlobalActorContext: _ActorContext {}

// If necessary, this protocol could get special treatment allowing for existentials
// until generalized existentials are a feature
protocol Actor {
    // If users ever specify an explicit ActorContext without conforming to `GlobalActor` 
    // they get a warning or error
    associatedtype ActorContext: _ActorContext = Never
}
protocol GlobalActor: Actor {
    associatedtype ActorContext: GlobalActorContext
}

With this design in hand, my Store class would use a conditional conformance:

final actor class Store<Value, Action, Context> { ... }
extension Store: GlobalActor where Context: GlobalActorContext {}

API that needs to rely on actors sharing a serialization context would be written to constrain the context of both actors to be identical and to conform to the GlobalActorContext protocol (and therefore only available on some instances). Any API whose implementation does not rely on that constraint would be available on all instances, even those with a unique serialization context.

It is a class that serializes access to state. I don't think the details very relevant to this discussion.

Can you explain what an ActorContext is that’s different from an actor? Feels like there’s just a lot going on here that isn’t clicking for me. You just want a type that serializes work but sits parasitically on another actor?

First, i'm amazed that swift get to have actors. Congrats to the team. IMHO this singlehandly could renew people's interest for the language in a server-side environment. Now for my question:

What's the target number of actors expected to run in a given system (let's say order of magnitude per cpu) ? From my understanding, great care has been put in the proposal to separate the actor definition system, from the thing actually running the functions (the task executor if i understand correctly). However, i suppose that authors of the proposal had at least some ideas of the types of usages, and the acceptable performance tradeoff they're ready to take. For example :

  • in a video game server, are we expected to spawn : one actor per "arena / map / game" ? , or one actor per "connection / player", or one actor per map item (every object in the world is its own actor) ? This could be the difference between having 10 actors per CPU, to 1000 to a million.
  • in a social network mobile app : are we expected to run one actor for UI (default) and one actor for background tasks (let's say, server side communication) ? or one actor per friend ? or one actor per message (dealing with its own status, like, reply, etc). Here again, the order of magnitudes could be widely different.
3 Likes

An ActorContext is modeling what your pitch calls a "global actor" in the type system. My design would have UIActorContext instead of @UIActor. An "actor" would be a class instance that lives within the rules of the actor system. An "actor context" would be the serialization context in which actor instances can run.

This distinction is already latent in your design where actors that are annotated with @UIActor live in a shared serialization context. I think it's useful to make it explicit.

I recall hearing of or reading about an actor system that had a similar notion. They called it a "vat" - a vat could have many actors in it and it provided a serialization context for all of those actors, allowing code to take advantage of the knowledge that this context is shared. I haven't been able to dig up any references on this, but have used the idea in my own code and found it very useful. This allows you to have some control over (and often reduce) the granularity of serialization boundaries.

The reason I introduced the actor context protocols is to allow Never to be used as an ActorContext that means “no shared context, each instance has its own queue”. If we didn’t need to do that (or if we had != constraints) we wouldn’t need the context protocols.

The programming model is not that different from yours in terms of conceptual or syntactic weight:

@globalActor
struct MyGlobalActor { }

@MyGlobalActor
actor class MyActor {}

vs

struct MyGlobalActorContext: GlobalActorContext { }

actor class MyActor: GlobalActor {
    typealias ActorContext = MyGlobalActorContext
}

It’s slightly more verbose, but has all of the advantages that come with working within the existing language and type system. I think magic attributes make sense in some cases, but not when a protocol-based design is both possible and useful without imposing a meaningful burden on less experienced programmers (i.e. without violating the principle of progressive disclosure).

2 Likes

I find this idea to be very interesting. We certainly do need to allow async functions on actors, because you need to be able to interact with the asynchronous world. However, letting synchronous actor functions be called as async on non-self instances lets us maintain the model's consistency without introducing lots of sync/async overloading or pushing code to async that doesn't need it.

Doug

9 Likes

@Lantua mentioned this as well. I like the idea.

You won't quite get here. There are no async properties, so you can't asynchronously access a var within an actor.

You can define @actorIndependent computed properties that can be used from outside. They're restricted to not touch mutable state in the actor, but it's a reasonable evolution path if you started with a let.

No need to be dramatic. The proposal is completely up-front about the tradeoffs being made by the design and its authors are open to discussion on the right design and tradeoffs.

Any solution to the reference-type problem would have to deal with this. The actorlocal notion mentioned in the road map is an aspect of the type; a cross-actor reference to a let whose type is actorlocal would be ill-formed (because, you know, it's local to that actor).

I can see why this is a problem for your ActorSendable design, because let access is synchronous and there's no point where you can safely do the implicit copy.

Whether the potential for trouble in the ActorSendable design makes let access a bad idea or not, I'm not sure: I'd like to see how more of the design shakes out.

You've conflated the two features here to draw a fairly strong conclusion. We've talked about let above; if you have concerns about @actorIndependent, it would be best for you to convey those directly and also consider the use cases that @actorIndependent fulfills.

I'm not opposed to this. We're trying to break things up into digestible proposals without having so many little proposals running around that folks can't keep track.

This is what global actors are for, but as you noted earlier...

As noted above, you can't simply "flip the behavior" here. I recommend you consider how to conform an actor class to CustomStringConvertible once you've taken away the let behavior and @actorIndependent.

Inheriting from NSObject is currently the only way to get conformance to NSObjectProtocol. You also need to inherit from NSObject (directly or indirectly) to mark a class as @objc. I looked at other options, and accepting this NSObject-shaped inheritance wart seems like the least bad option.

Yes, or we should add the notion of a "concurrent, non-escaping" function type to the mix. We had a thread on this somewhere, but I can't find it at the moment. Short version: we could add "concurrent" to function types and it would provide some benefits here over always falling back to "escaping", but it also complicates the type system. Tradeoffs.

My thinking here was that one could take a class that might be hard to turn into an actor, e.g., because it's enmeshed with a non-actor class hierarchy, and conform to the Actor protocol. We could then say that calls to async functions on such a class would get scheduled on the actor, so you're getting the hop-to-queue behavior for async calls (== less boilerplate) for free, but not the advantages of enforced data isolation.

That said, this is all very fuzzy and I'm not at all convinced that this kind of half-actor class is going to useful in practice.

I had not expected this view point at all, but this explains your comments about @actorIndependent. Not being able to allow actors to conform to existing, synchronous protocols at all seems like it would make actors hard to integrate into existing Swift programs. I mentioned CustomStringConvertible, but Identifiable and comes to mind as being important, and a distributed actor system would sure like to make Codable work.

Thanks for the feedback.

Doug

12 Likes

You mean the ones started here?

+1 (as in, it doesn't sound very useful in practice).

1 Like

While using sync calls seems to be a kind of pessimistic locking - async suspension points feel like an optimistic strategy. Maybe that’s some idea for using STM in the future where an implicit transaction is started on entering an actor method from outside.

So I was figuring out how actors should be treated by the type system. I'll leave this here since it should still be useful whether or not actors are part of the type system (vs part of declaration).

Let's start with the largest systemic rule, with each closure has 3 orthogonal properties (abbreviation in parentheses):

  • escaping (esc) < non-escaping (-)
  • actor independent (I) < self actor (S), global actor (G)
  • sync (-) < async

We also want a few extra rules so that calling from different actor is done asynchronously:

  • S < I async
  • G < I async
  • S esc < I esc async
  • G esc < I esc async

That's 12 combinations and 18 basis relations between them (not to mention relations from transitive rules). It's a pretty big poset given that it applies to each function type, e.g., (Int) -> (). Nonetheless, this gives us a good sanity check for other subtyping rules since that system needs to be congruent with this one (or else we'd be missing something).


Now, we can shrink the poset by merging these combinations:

  • S async + G async + I async -> async group,
    • We can convert S async and G async to I async by immediately hop onto the right actor,
  • S esc + S esc async + G esc async + I esc async -> esc async group
    • Similar to above, we can convert them to I esc async,
    • self-actor functions can't escape, convert S esc to I esc async instead.
  • S + G -> A
    • There's no notable distinction between S and G, so we can use A for both.
  • G esc -> A esc.

Now we're left with 2 axes, 6 combinations, and 7 relations:

  • actor independent (I) < actor isolated (A) < async group
  • esc < (non-esc)

or

I esc -> A esc -> esc async group
  |        |          |
  v        v          v
  I   ->   A   ->   async group

Interestingly, S esc somehow got pushed onto esc async group instead of A esc. :thinking: So this type system would lose the ability to convert S esc (in esc async group) to S (in A).


One question is where to put functions with no actor restriction/guarantee, i.e., old closures. Since there's no actor restriction, it should be together with the actor-independent (I) category. It'd restrict a lot of actor-related code from forming closures for outside consumption, but would be safe from DispatchQueue.concurrentPerform(_:).


Added:

Potential naming for the system above:

@escaping -> @UIActor @escaping -> @escaping async
    |                |                   |
    v                v                   v
  (n/a) -> @UIActor, @actorIsolated -> async

where @actorIsolated is allowed on local variable only.

If we don't want global actors to be type significant (because users can add them?), we can also push G esc and G into esc async group and async group, respectively, resulting in:

@escaping       ->       @escaping async
    |                          |
    v                          v
  (n/a) -> @actorIsolated -> async
3 Likes

Ok, I ended up liking this last system a lot. If we change the defaults a bit:

    @escaping          ->          @escaping async
        |                                 |
        v                                 v
@actorIndependent -> (actorIsolated) -> async

This would retain most of what we want without mentioning a specific actor at all:

// Inside X.foo(other: X)

// esc async
let ea0 = { self.state } // self-actor
let ea1 = { other.state } // other-actor
let ea2 = { // no actor, needs await
  await self.state
  await other.state
}

// concurrentPerform(_: @actorIndependent () -> ())

let a0 = array.map { state[$0] } // (actorIsolated)
let a1 = array.map { sharedState } // actor independent
let a2 = array.map { other.state[$0] } // Error

let c0 = concurrentPerform { sharedState } // actor-independent
// error, cannot convert actor-isolated to actor-independent
let c1 = concurrentPerform { state }
// error, cannot convert async to actor-independent
let c2 = concurrentPerform { other.state }

Though we need to change the signature of all concurrentPerform-like functions, which should be rare enough.


If actorIndependent is so rare that we don't need a special keyword at all, we can push it along the poset line to async (as opposed to escape in the current pitch).

This way, we can do:

// // concurrentPerform(_: () async -> ())
let d0 = concurrentPerform { sharedState } // (actorIsolated)
let d1 = concurrentPerform { state } // async
let d2 = concurrentPerform { other.state } // async

which should at least be valid (albeit defeating the purpose of concurrentPerform).

1 Like

I have a concrete example which I'd like your opinion on. Let's suppose we have a program in which we start to use actors, here's one random function which returns some internal state:

actor class UserSettings {
    func getAccentColor() async -> Color
}

The function is async because it has to be. Isn't it a bit odd though? This function doesn't perform a long-running task or something inherently async like a network request. Now the code calling this function needs to await on it, and all of a sudden things get more complicated, because the whole chain of calls needs to turn async. This assumes first that chains of calls can actually be made async in a reasonable fashion, that for example there is no synchronous call up the chain that is out of the developer's control (suppose a framework/library calling the developer's code synchronously and expecting a result). Furthermore, at any level in the caller chain, it might not be expected to be able to execute other functions while awaiting, something that now becomes a possibility, and it now requires further code audits and non-trivial changes to protect code from executing in an inconsistent manner. Now scale this to an entire program. Doesn't it seem overly complicated and dangerous to push async interfaces like this? Should this function really be async? Nobody seems to be discussing this problem but it seems like a real issue to me. Do you all expect this to not be an actual problem when people start using actors?

4 Likes

Unless there is some way to synchronously call an async method to stop the infection then this is almost certainly an issue. There's numerous ways to break the chain in C#, e.g.

var result = someFunctionAsync(...).Result;

...but there's no single right answer because it depends on your circumstances, and I'd wager the vast majority of async/await users don't know enough to reason about which is correct.

Are you talking about race conditions where a method calling an async function can potentially be re-entered on the same thread?

That is one example yes. But I mean more generally. As soon as you await on something, you need to think hard about things that you didn't need to think about before. You need to consider that the current context of execution has been released back to the caller, and now it might be free to perform new calls in the program (things might have been queued up there waiting for execution). This opens all sort of very tricky out-of-order bugs that couldn't happen before. For the developer, it's very difficult to reason about this, and it's very difficult to be confident that the program will always behave correctly.

Indeed this is what developers usually end up doing but you wouldn't want to encourage that pattern. Because this code is blocking the current thread while waiting for another thread to complete work. This can lead to thread explosion, deadlocks, and I believe the libdispatch maintainer at Apple called this pattern a "performance suicide".

1 Like

Hi Doug,

I think this is a fairly fundamental difference in world view. I'll lay out what I'm suggesting:

  1. As proposed: Actors can have sync and async methods, and properties/subscripts (really, their getters and setters) are always sync. Intra actor calls can use both directly. Also, inout uses across actor boundaries are not allowed.

  2. Unlike what is proposed: cross actor references obey access control like normal, both for methods and properties. All cross actor references are gated by ActorSendable check on parameters and results. No special case for let.

  3. Unlike what is proposed: Any reference to a cross-actor sync functions is allowed (subject to standard access control and ActorSendable check), but is implicitly an async reference and needs to be awaited.

The payoff of this is several fold:

  1. Our complicated access control model doesn't get any more complicated.
  2. You don't need wrappers for sync functions and introduce naming problems as mentioned above.
  3. All properties/subscripts are directly usable across actor boundaries, since their getter/setter is just a sync function that returns/takes a T and is treated like any other sync function.

This is a simple and consistent model. It doesn't require special cases for let's and doesn't complicate access control. It doesn't change our resilience model with lets. It defines away most of the need for @actorIndependent.

Incidentally, I find @actorIndependent to be highly dubious - why would these things be defined on the actor instances if they are independent of it? Isn't this just a static actor member?

-Chris

4 Likes