book: Fix final dining philosophers program output

[danmactough]

• Fix final dining philosophers program output to match what the program actually outputs
• Clarify that only one philosopher can eat at a time (as currently implemented, at least)

[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. Due to 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]

Hey @danmactough ! I'm still not sure why this is different for you, as I copied it directly from running. Hm.

They should be able to eat at the same time, though the timing may not always work out that way.

[danmactough]

Hey @steveklabnik ! I don't know either! :) My code is here but the only diff from the docs (I git diffed) was EOF whitespace.

I was wondering if the implementation changed since you copied that output. Just thinking about it logically the way it's being implemented, I can't see how anything other than what I observed could happen.

• phil0 picks up fork0 and waits 150ms
• phil1 picks up fork1 and waits 150ms
• phil2 picks up fork2 and waits 150ms
• phil3 picks up fork3 and waits 150ms
• phil4 cannot pick up fork0 -- phil4 waits for fork0
• phil0 timeout expires, but fork1 is taken
• phil1 timeout expires, but fork2 is taken
• phil2 timeout expires, but fork3 is taken
• phil3 timeout expires - phil3 pickup fork4 and eats
• phil3 finishes and returns fork3 and fork4
• phil2 is unblocked, picks up fork3 and eats
• etc.

[sfackler]

@danmactough why do you believe that philosopher 0 will always run first? Threads do not necessarily execute in exactly the order they're spawned.

[danmactough]

why do you believe that philosopher 0 will always run first?

It never occurred to me that ...

Threads do not necessarily execute in exactly the order they're spawned

In part, because I ran the code probably a hundred times and got the same output (which doesn't match the current docs).

Thanks for the tip, @sfackler! I added a little more output to my code and can see what you're saying now:

        thread::spawn(move || {
+           println!("{} starting", p.name);
            p.eat(&table);
        })

Still... I have never seen two philosophers eating together (not since college, at least).

I think the docs for this exercise -- which is about learning Rust -- shouldn't present an edge case (if that's accurate) as the norm and assume that a beginner (me) would connect the dots -- i.e., that since spawned thread execution order is arbitrary, it's remotely possible that two philosophers could eat at the same time if the order of execution is just so. It sure confused the heck out of me. I was certain that I had missed something in my code.

I've reverted my initial change and instead suggest a clarification just to the wording: 7dc7531.

[danmactough]

closed by #30595