Skip to content

[SoruceKit] Audit SwiftASTManager to prevent deadlocks #58978

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented May 19, 2022

After fixing #42258, I re-audited SwiftASTManager to prevent any further deadlocks by further narrowing locks scopes and making sure that some callbacks are always called from a background queue that can’t have claimed any locks.

  • Ensure that no callbacks are called when either of these mutexes are held:
    • SwiftASTConsumer::CancellationRequestCallbackAndIsCancelledMtx
    • ASTBuildOperation::DependencyStampsMtx
      • Exception: We allow calls to getBuferStamp because that doesn’t claim any locks)
      • No change was necessary here
    • ASTBuildOperation::ConsumersAndResultMtx
    • ASTBuildOperation::CacheMtx
      • No change was necessary here
    • ASTBuildOperation::ScheduledConsumersMtx
      • Make sure we always inform the consumers asynchronously, even if the operation was already cancelled when the consumer got enqueued by introducing ConsumerNotificationQueue
  • Ensure that all callbacks to SwiftASTConsumer (i.e. requestCancellation and handlePrimaryAST, failed, cancelled) are performed asyncronously from a queue to avoid deadlocks

rdar://110357502

@ahoppen ahoppen requested a review from bnbarham May 19, 2022 10:06
@ahoppen
Copy link
Member Author

ahoppen commented May 19, 2022

@swift-ci Please smoke test

@ahoppen ahoppen force-pushed the pr/no-deadlock-cancellation-bigger-change branch from 91f4f24 to c573332 Compare June 21, 2023 10:34
@ahoppen ahoppen requested a review from rintaro as a code owner June 21, 2023 10:34
@ahoppen ahoppen force-pushed the pr/no-deadlock-cancellation-bigger-change branch from c573332 to 39a459e Compare June 21, 2023 10:34
@bnbarham
Copy link
Contributor

bnbarham commented Jun 22, 2023

That's a lot of mutexes, locks, and queues 😓 Changes seem reasonable to me, but in general this feels somewhat fragile. I do wonder if such fine grained locking is really worth it in these cases but since we already have it 🤷

@ahoppen
Copy link
Member Author

ahoppen commented Jun 22, 2023

@swift-ci Please smoke test

@ahoppen
Copy link
Member Author

ahoppen commented Jun 22, 2023

@swift-ci Please smoke test Windows

- Ensure that no callbacks are called when either of these mutexes are held:
  - `SwiftASTConsumer::CancellationRequestCallbackAndIsCancelledMtx`
  - `ASTBuildOperation::DependencyStampsMtx`
    - Exception: We allow calls to `getBuferStamp` because that doesn’t claim any locks)
    - No change was necessary here
  - `ASTBuildOperation::ConsumersAndResultMtx`
  - `ASTBuildOperation::CacheMtx`
    - No change was necessary here
  - `ASTBuildOperation::ScheduledConsumersMtx`
    - Make sure we always inform the consumers asynchronously, even if the operation was already cancelled when the consumer got enqueued by introducing `ConsumerNotificationQueue`
- Ensure that all callbacks to `SwiftASTConsumer` (i.e. `requestCancellation` and `handlePrimaryAST`, `failed`, `cancelled`) are performed asyncronously from a queue to avoid deadlocks

rdar://110357502
@ahoppen ahoppen force-pushed the pr/no-deadlock-cancellation-bigger-change branch from 39a459e to 453f6cd Compare June 23, 2023 14:56
@ahoppen
Copy link
Member Author

ahoppen commented Jun 23, 2023

@swift-ci Please smoke test

@ahoppen ahoppen merged commit 22d34d9 into swiftlang:main Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants