Reorganize concurrency course

[djmitche]

• Organize similar to Fundamentals: shorter segments each ending with an exercise
• Put the entire course under src/concurrency (it's currently under src/{concurrency,async})
• Move exercises into the source directories as done with Fundamentals
• More, simpler exercises
• Try to factor out the "pitfalls" segment of the async session
• Cover sync primitives like Mutex (since they're used in dining philosophers)

[fw-immunant]

I'm open to discussion, but I think the current format of the concurrency course works really well. What makes you feel that shorter segments with more exercises would be an improvement?

What other designs have you thought of for the "pitfalls" segment? One additional pitfall I usually discuss is lock poisoning, and how the stdlib embraced a pattern that adds a lot of noise to enable robustness while Tokio rejected the concern in favor of a simpler interface. That said, I usually discuss that topic with the solutions for the async philosophers exercise, where it's worthwhile to diff the solution against the threads-based implementation to see the reason for each difference.

We do presently have a slide about Mutex<T>.

[djmitche]

I'm open to discussion, but I think the current format of the concurrency course works really well. What makes you feel that shorter segments with more exercises would be an improvement?

Only that that was a major part of the v2 work on Fundamentals, and I think that's been well-received. It would still have "sync morning" and "async afternoon", and roughly the same number of segments, just with a smaller exercise after each segment. My sense is that these exercises are "too big" and take students wildly different amounts of time to solve, so optimizing for shorter, better-encapsulated exercises would help.

What other designs have you thought of for the "pitfalls" segment? One additional pitfall I usually discuss is lock poisoning, and how the stdlib embraced a pattern that adds a lot of noise to enable robustness while Tokio rejected the concern in favor of a simpler interface. That said, I usually discuss that topic with the solutions for the async philosophers exercise, where it's worthwhile to diff the solution against the threads-based implementation to see the reason for each difference.

SUMMARY for my WIP is here. Basically it's spreading the "pitfalls" out across the places where they are relevant, instead of spending 45 minutes essentially talking exclusively about how awful async is.

Good point about mutex poisoning!

We do presently have a slide about Mutex<T>.

---

I'd appreciate your having a quick look at my branch, much as it's a work-in-progress. I'm happy to scale it back, and especially if you've had good experiences with the exercises at the end of each session I can keep that model.

True! I either missed that, or made that comment before it existed :)

[mgeisler]

Hi folks! I'm late to the party, but I hope I can add some comments here.

I'm open to discussion, but I think the current format of the concurrency course works really well. What makes you feel that shorter segments with more exercises would be an improvement?

I taught the class recently in London (in-person) and there we unfortunately didn't have time for the exercises. That was mentioned in the course feedback by several of the participants.

This is partly my fault for spendign too much time talking and showing things, but I also felt the exercises were too big. I've taught Concurrency Morning several times and seen 1-2 people complete the 62.2. Multi-threaded Link Checker in 30 minutes.

We have smaller exercice in 61.3. Example. It's not presented as an exercise, but I normally solve it by asking the class for "help". I think it would be good to turn this into a 10 minute exercise.

For the async afternoon, I felt that 63.4. Tasks was too big of an example. The slide only needs to introduce the concept of an async task so a full-blown echo server felt quite complicated at this point. The await keyword has only been seen once or twice (on 63.1. async/await) at this point.

I also found 64.2. Select hard to explain: there is a lot going on there. While I appreciate the analogy between animals racing to the finish line and select! racing the two futures, I think it could be simplified to focus on the core idea.

[djmitche]

Thanks! This branch has definitely gotten out of date. I sat in on @fw-immunant's teaching of the course a few weeks ago and gathered some timing information there. I'm currently working on a much-reduced refactor of the course:

• Break into segments at approximately the places @fw-immunant put breaks
• Move all of the files into src/concurrency
• Add timings and segment/session metadata so course outlines appear

Once that's done, we can consider further changes -- for example, maybe as @mgeisler has suggested we could remove the multi-threaded link checker exercise and add a smaller exercise to one of the segments.

[djmitche]

#2048 adds a state machine. @fw-immunant please feel free to edit that implementation -- you came up with one on the fly and I wish I had grabbed a screenshot!

There's still more work to do here.

• Less-intense exercises -- leaning more toward the exercise-per-segment approach from the fundamentals course
• More examples of await, maybe in exercises. The tricky bit is, until we cover runtimes, there's nothing to await!
• Simplify select! example
• (from @fw-immunant) It's unclear what's intended by the suggestion to re-initialize the timer on the Pin/select! slide