Illustrate deadlock in dining-philosophers.md

[Sean1708]

Originally the program would not (or would only very rarely) deadlock even if the numbers were in the "incorrect" order (4, 0). This means the statement

But there’s one more detail here, and it’s very important. If you look at the pattern, it’s all consistent
until the very end. Monsieur Foucault should have 4, 0 as arguments, but instead, has 0, 4. This is
what prevents deadlock, actually: one of our philosophers is left handed!

could be very confusing, if no deadlock occurs why would the detail be very important?

This change means that a deadlock will (almost?) always occur if the numbers are in the order 4, 0, allowing people to see why the change is actually needed.

r? @steveklabnik

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[steveklabnik]

could you make this around, please?

[steveklabnik]

So, while I do appreciate that this increases the likelihood of a deadlock, it now means that the printf! statements are out of sync with what they're supposed to be simulating. You can't eat until you have both forks...

[Sean1708]

I think I've addressed your concerns about the println! statements.

Personally I think this is a worthwhile change, when I went through the tutorial the other day I spent an embarrassingly long time trying to figure out why switching the order didn't change anything. Then again, I might be an outlier in that regard.

[steveklabnik]

I still think this kinda messes it up, though. The idea is to acquire both locks, then sleep for the second.

Maybe it would be better to keep the code as it was, but put a smaller delay between the attempt to acquire each lock?

I originally adapted this code from other implementations too, so I'm a bit concerned about being non-standard in this regard, know what I mean? Like, looking at the Rosetta Code implementations for other languages, we do the same thing.

[Sean1708]

That's fair enough, I think the best thing will probably be to leave it as it was then (I don't think a smaller delay would work, there needs to be a delay between picking the forks up). At the end of the day, the people who want to play will play and figure it out on their own.

[bors]

☔ The latest upstream changes (presumably #26990) made this pull request unmergeable. Please resolve the merge conflicts.

[steveklabnik]

Sounds good, yeah. Thank you for talking it through with me!