[Concurrency] Actors & actor isolation

Evolution Pitches
58

I agree that this is a critical problem and that solving it is a huge opportunity and will be a huge contribution for Swift concurrency. Unfortunately, "phase 1" of the plan here doesn't solve this. It is introducing a memory unsafe actor model akin to Akka actors. This is a very useful step in that it provides a design pattern to help structure concurrent code, but is not far enough IMO. Also, taking a half step here will introduce serious problems with getting to the memory isolation and race safety.

As I mentioned in the roadmap thread, we can pretty easily fix this. I will try to get an outline of this together today or tomorrow to share with the community. UPDATE: it's in this thread.

Here is a detailed review of this draft of the proposal. I include a few large topics that need detailed discussion on their own, then a number of smaller points at the end. I'm really thrilled to see the progress in this area!

actor class vs actor

Much of the discussion upthread is about actor class vs actor. I tend to agree with people that actors are primal enough to be worth burning a keyword on, here is some rationale:

  1. The documentation and diagnostics will inevitably all talk about "actors" and not "actor classes", so it makes sense to align the language with this.
  2. Actors can't subclass classes and visa-versa, they are a "different thing"
  3. They are a "another kind" of reference type in Swift (along with classes, functions, unsafe pointers, etc).

At the very least, I would recommend capturing some of the tradeoffs in alternatives considered section. On the flip side, calling them actors means we would have to survey all of the places we use classes and reconsider them, e.g. class methods, how to rationalize actors subclassing NSObject (see below), etc. I think it is reasonable for actors to not have static members and class methods though, as the whole idea is to get rid of global state.

Separating access control from async for cross-actor reference validity checks

"Synchronous functions in Swift are not amenable to being placed on a queue to be executed later. Therefore, synchronous instance methods of actor classes are actor-isolated and, therefore, not available from outside the actor instance." ... "It should be noted that actor isolation adds a new dimension, separate from access control, to the decision making process whether or not one is allowed to invoke a specific function on an actor. " <== Please let's not do this! :slight_smile:

I mentioned this to John previously, but it seems better to keep access control orthogonal to cross-actor reference issues. The proposed design will end up producing a lot of async wrappers for sync functions just to allow those sync functions being called across actor boundaries. There is no need for this boilerplate:

actor class BankAcount {
   .. state..

   // This method is useful both within and from outside the actor.
   public func computeThing() -> Int {
      ...
   }

   // I need to manually write a wrapper, and now I have a naming problem.  :-(
   public func computeThingForOthersToUse() async -> Int {
     return computeThing()
   }
}

Instead, I'd recommend make the model be that cross-actor calls are defended by access control like normal, and a cross actor call to a sync function is implicitly async (thus requiring an await at the call site):

   // some other actor can call the sync function, because it is public!
   await use(myBankAccount.computeThing())

The compiler would synthesize the thunk just like it does reabstraction thunks. This provides a more consistent programming model (not making our access control situation more complicated) and eliminates a significant source of boilerplate. Similarly (as part of the base async proposal), it should be possible to fulfill an async requirement in a protocol with a normal sync method implementation.

This realigns the async modifier on actor methods to be about the behavior of the method, not about whether it can be called by other actors, which is what access control is about.

Your deposit(amount:) example is a great illustration of the problem here: there is nothing about its behavior or implementation that leads to internally suspendable. Declaring it as async means that any intra-actor calls will have to await it for no reason.

Furthermore, doing this solves a significant amount of complexity elsewhere in the proposal: accesses to cross-actor state (whether it be let or var) is gated simply by access control. Any cross-actor access would be correctly async, and synchronization in the most trivial cases allowed by the proposal would be optimized out by the compiler using the as-if rule. This keeps the programmer model simple and consistent.

More related points in the "let" section next:

Cross actor let property access

I am very concerned about allowing direct cross-actor to let properties, because we don't have the ability to support computed let properties. Allowing this will harm our API evolution of properties: we currently allow things to freely move from let properties to vars with public getters, but this will break that. I don't think that "let-ness" is resilient across library boundaries at all right now (for good reason).

Furthermore, as you mention, reference types completely break the actor memory safety guarantees here, the entire stated purpose of this proposal. :-) You don't want cross-actor uses of this thing to have access to data your mutating within the reference type. You need something like the reference type proposal (which I'm hoping to work on) to gate this.

I feel like you're trying to walk an awkward line here, and I don't think it will work well: actors are supposed to be islands that can only be "talked to" asynchronously. The "let's and @actorIndependent things can be talked to synchronously" breaks the contract and muddles the water.

Overall, I would recommend subsetting this out of the initial proposal and discussing it as a later extension. It isn't core to the programming model, and introduces a lot of issues.

Global actors

On global actors in the detailed design section, I don't understand the writing and what is being conveyed here. There are both small and large examples of this. Some larger questions:

  • What does "The custom attribute type may be generic. " mean? Does this mean that @globalActor struct X<T> { is allowed? If so, the semantics are that there is one instance of the actor for each dynamic instantiation of the type T, right? I think that this is required because shared will be instanced multiple times.

    This is a very powerful capability: is there a use case for it? If not, I'd recommend subsetting it out of the initial version of the proposal, it can always be added later.

  • I don't understand what this means: "Two global actor attributes identify the same global actor if they identify the same type." Don't they have to be lexically identical attributes if that is the case?

  • There are some implied semantics of a declaration being marked as a global actor, but I'm not sure what they are.

  • The whole discussion of "propagation" of the global actor attribute is vague and I find it to be confusing.

I would recommend splitting this whole discussion of global actors out to its own sub-proposal. The issues involved are complicated and could use its own motivation, examples, and exploration to develop it, and this is additive on top of the base actor model. To be clear, I'm not saying that we should adopt actors without solving this proposal, I just think that it would be easiest to review and discuss it as a separate thing.

Other

Some more minor comments and questions:

  • Writing/framing nitpick: "The primary difference is that actor classes protect their state from data races." --> I don't think this is the primary difference between actors and classes. The primary difference is that actors have a task/queue associated with them, and they are used as a design pattern in concurrent programs. Actors are not guaranteed to protect state, e.g. in the face of unsafe pointers.

  • The behavior with escaping closures and actor self makes sense to me.

  • The "Escaping reference types" section is really troubling as I mentioned at the top. I don't think that this proposal can stand alone without a solution to this problem.

  • Actor isolation also needs a solution for global state like global variables and static members of classes. I don't think the "proposed solution" section or "detailed design" touches on this at all.

  • Another writing issue: The discussion of @globalActor and @UIActor in the "proposed solution" section is too vague for me to understand it.

  • "As a special exception described in the complementary proposal Concurrency Interoperability with Objective-C, an actor class may inherit from NSObject." --> It isn't clear to me why this is needed. Isn't enough to mark the actor as @objc? I thought all @objc things already inherit from NSObject?

  • As I mentioned above, I think that the way you are conflating access control with cross-actor references is confusing and problematic. This @actorIndependent attribute is another example of this. I think this whole topic needs further consideration. Flipping the behavior as mentioned above seems like it would simplify the proposal significantly, by relying on our (already overly powerful) existing access control mechanisms.

  • Shouldn't the closure parameter to run be @escaping? If not, you can trivially violate the actor safety properties due to the self capture rules described earlier in the proposal.

  • On enqueue(partialTask:): I love that this is user definable. Why can't it be marked final? This seems like it should only be defined on root actors though. I'd love to see a longer exploration of this topic on its own, because just this single method has a huge set of tradeoffs that are worth exploring.

  • "Non-actor classes can conform to the Actor protocol, and are not subject to the restrictions above. This allows existing classes to work with some Actor-specific APIs, but does not bring any of the advantages of actor classes (e.g., actor isolation) to them." Ok, out of curiosity, why is this important? I can see the utility of having an actor protocol that unifies all the actors, but I don't see why it is useful for normal classes to conform. I also don't see any harm, just curious what the utility is.

  • As I mentioned a couple times above, I would rather not have @actorIndependent at all, I'd rather that cross-actor accesses be gated by normal access control, and any cross-actor reference just being async. This seems like it will lead to a simpler model, less boilerplate, and less language complexity.

  • I also don't think there is any great need to have actors be able to provide non-async protocol requirements. This seems directly counter to the approach of actors. Such a need can be handled with simple struct wrappers, which seems like it would factor the language complexity better.

  • I don't understand what is being conveyed in the "Overrides" section. An example would be very helpful.

Overall, I'm very very excited to see the progress on this. This is going to transform the face of Swift programming at large!

-Chris

22 Likes