Skip to content

Conversation

@ryzngard
Copy link
Contributor

Takes document version tracking off the dispatcher thread requirement and uses a locking mechanism instead.

@ryzngard ryzngard requested a review from a team as a code owner July 26, 2023 00:59
Copy link
Member

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In isolation this makes sense, so I'm clicking approve, but something that isn't clear to me is the impacts of moving this to have its own lock, versus previously when it would share the dispatcher (and the implied "lock" that gave) thread with all other project operations. Every single integration test failing does not fill me with confidence either 😛

Should the snapshot manager expose its lock for others to use?

…tDocumentVersionCache.cs

Co-authored-by: David Wengier <[email protected]>
@ryzngard
Copy link
Contributor Author

In isolation this makes sense, so I'm clicking approve, but something that isn't clear to me is the impacts of moving this to have its own lock, versus previously when it would share the dispatcher (and the implied "lock" that gave) thread with all other project operations. Every single integration test failing does not fill me with confidence either 😛

Should the snapshot manager expose its lock for others to use?

I think not for now. The final straw would be if we got RazorProjectService off the dispatcher thread. Then I think we'd need a shared lock. I'll think more on it, and am happy to discuss, but this unblocks us allowing multiple readers async which I think is the biggest perf portion. To the point where I wouldn't even mind putting the assert back for mutation, just so we know that mutation happens in the same order still (it should)

Copy link
Contributor

@allisonchou allisonchou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

private void TrackDocumentVersion(IDocumentSnapshot documentSnapshot, int version, string filePath, ReadWriterLocker.UpgradeableReadLock upgradeableReadLock)
{
// Need to ensure the write lock covers all uses of documentEntries, not just DocumentLookup
using (upgradeableReadLock.EnterWriteLock())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might just be me not understanding locks properly, but is there a reason why we're using using () syntax instead of using var _ syntax as we do in most other parts of this file? Is the intention to just be more explicit about the scope of the write lock?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For write locks we're being a bit more explicit about where it is held, since they block all other operations.

@ryzngard ryzngard merged commit 2a06d37 into dotnet:main Jul 26, 2023
@ryzngard ryzngard deleted the remove_versioncache_dispatcher branch July 26, 2023 21:42
@ghost ghost added this to the Next milestone Jul 26, 2023
333fred added a commit to 333fred/razor that referenced this pull request Aug 23, 2023
* upstream/main: (188 commits)
  Rename CSHTML file reference. (dotnet#8969)
  Remove Omnisharp logic from main branch (dotnet#9027)
  Update dependencies from https://github.com/dotnet/arcade build 20230726.1
  Fixes CVE-2023-33127 and CVE-2023-33170 (dotnet#9032)
  Remove Async Keyword For Generate Async Method Code Action (dotnet#9030)
  Remove dispatcher from DocumentVersionCache (dotnet#9026)
  Restore perf work. (dotnet#8995)
  Implement priority trigger support
  Change implementations and references
  Rename ProjectSnapshotChangeTrigger and convert to interface
  Updates after merge
  Fix nullability
  Use pattern matching
  Convert to record struct
  Move CloseTextTagOnAutoInsertProvider to FindToken (dotnet#9025)
  Move GenerateMethodCodeActionProvider to FindToken (dotnet#8988)
  Add comment describing when ProjectRazorJson.Version should be incremented
  Some more violations, after the merge
  Remove TryResolveDocument method
  [Infra] 17.8 P1 snap PRs (dotnet#9021)
  ...
@Cosifne Cosifne modified the milestones: Next, 17.8 P3 Sep 25, 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.

4 participants