Skip to content
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

remove use of upgradable reads from derived queries #75

Merged
merged 1 commit into from
Dec 28, 2018

Conversation

nikomatsakis
Copy link
Member

No description provided.

@nikomatsakis
Copy link
Member Author

I'm now thinking that this PR is not necessary. But I'm trying to write out a comment clearly explaining what went wrong and why I think we're ok and dang is it hard. =)

The TL;DR of why I think we're ok now is once we acquire this particular upgradable-read, we will always release it without blocking on any other locks (apart from the mutex guarding the dependency graph, but that is always a "leaf lock" so we should be ok).

@matklad
Copy link
Member

matklad commented Oct 31, 2018

I feel maybe we should stick to read/write access for the time being, just to make debugging deadlocks, should they reappear, easier. That is, I'd like to avoid thinking "oh, maybe its that upgrade lock again" when debugging.

We probably can put upgradable reads in back when parking_lot is fixed.

@matklad
Copy link
Member

matklad commented Oct 31, 2018

ut I'm trying to write out a comment clearly explaining what went wrong and why I think we're ok

I think the main problem here is that parking_lot's behavior does not match the docs, so it's difficult to reason about what are you trying to prove in the first place.

@matklad matklad mentioned this pull request Dec 22, 2018
@matklad
Copy link
Member

matklad commented Dec 22, 2018

@nikomatsakis see #99 for a deadlock which happens on those upgradable_read calls :-)

@nikomatsakis
Copy link
Member Author

I'd like to understand this deadlock, but I rebased.

@matklad
Copy link
Member

matklad commented Dec 24, 2018

I'd like to understand this deadlock, but I rebased.

I've mapped where each thread is blocked over here:
matklad@330b27d

This doesn't look like the "upgradable reads block reads" situation we've got before, because only writes and upgradable reads are involved, no plain reads. The next step would probably be to write a parking-lot stress test, like the one for reads. I sort of expect an "interesting" behavior of upgradable read here :)

@matklad
Copy link
Member

matklad commented Dec 27, 2018

@nikomatsakis see Amanieu/parking_lot#101 (comment) (a new example, mirroring what this PR is doing). Looks like it's a pl bug.

@nikomatsakis
Copy link
Member Author

Fascinating. OK, merging and publishing!

@nikomatsakis nikomatsakis merged commit dd1b6ed into salsa-rs:master Dec 28, 2018
nikomatsakis added a commit to nikomatsakis/salsa that referenced this pull request Dec 28, 2018
- Panic safety improvements (salsa-rs#81)
- We build on stable now (salsa-rs#94)
- Removed use of dynamic dispatch for constructing query
  descriptors (salsa-rs#95)
  - Technically a breaking change, though unlikely to affect clients
- Removed use of upgradable reads to avoid Amanieu/parking-lot#101 (salsa-rs#75)
- Upgraded parking lot (salsa-rs#100)
- Improved Debug output (salsa-rs#98)
- Snapshot implements Debug (salsa-rs#85)
@nikomatsakis nikomatsakis mentioned this pull request Dec 28, 2018
@matklad
Copy link
Member

matklad commented Jan 1, 2019

This bug is fixed in parking lot 0.7.1 so in theory we can perhaps revert this now? Though, I'd rather avoid using upgradable reads: even if they are bug free now, I'll still will be blaiming/testing them when facing with further salsa bugs :-)

And in general, it might be a good idea to improve locking infra once with have benchmarks to quantify improvements (FWIW, salsa is fast enough for everything I've thrown at it in rust-analyzer so far) :-)

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.

2 participants