Defining thread safety in Parallelism Lecture

[jespiron]

Edit: addressing in #43
See #42 (comment)
Ignore this body

---

The current conclusion is strong

Rather than choosing a restrictive "dogmatic" approach to concurrency, Rust supports many approaches, safely

To make this point clearer, I recommend defining thread unsafety:

• Condition 1: Shared memory
• Condition 2: An invariant of shared memory that must hold for correctness, like "count is the number of times any thread has executed this function"
• Condition 3: Invariant does NOT hold during part of the update
• Condition 4: Program is not thread-safe if another thread can access the shared memory while invariant is broken

We achieve thread safety by removing one of the above conditions

When we explain each approach, we can show which condition it removes:

• Mutual exclusion removes condition 4, by restricting access to at most one thread
• Atomics remove condition 3 by making update an airtight operation
• Message passing eliminates shared memory and thus all conditions, since each thread processes data independently through channels

[connortsui20]

I think this is slightly more complicated than it has to be, I believe that thread safety is simply the absence of data races. Since a data race is considered UB, thread safety is more generally just the absence of UB when working with threads.

See this entire chapter: https://doc.rust-lang.org/nomicon/concurrency.html

[jespiron]

Your definition is good! In light of the XY problem, I want to step back and explain why I’m suggesting this change.

Basically, the Parallelism lecture has a lot of good content, but it feels like a list of solutions. I’m grouping them under problems so it’s easier to follow.

My outline is

Problem: Concurrency
Solution: Parallelism => Multithreading

Problem: How do threads communicate?
Solutions: Shared Memory, Message Passing

Shared Memory
Problem: Shared memory is ingredient for data races
Solution: Mutual Exclusion, Atomics

Message Passing
Problem: Shared memory, while common solution for communication, is ingredient for data races
Solution: Message Passing eliminates shared memory

I notice a theme is justifying safety, so thread safety would be good to define. I prefer your definition of thread safety, as it’s easier to remember.

Aside from this safety discussion, the other question I appreciate insight is how we should wrap up this outline.

Currently, the lecture has extra topics that, while good, I can’t find a bigger narrative to fit them under (RwLock, Barrier, CondVar, Weak, …). Without a story to motivate these solutions, students will forget them. I think we should either

• remove them, or
• develop stories for them. I’m happy to do this, as I’ve used and implemented them in 418 + 410. However, I have a hard time tying them to our current outline, as the problems that these extra topics solve are very different.

So thoughts on how we should treat these extra topics are also appreciated. Thank you!

[connortsui20]

I think I understand what you're saying now, basically we only explain the different ways to invoke parallelism in Rust and don't really go in depth on why everything is safe.

This is a good point, but I'm worried that if we try to tie a comprehensive explanation of thread safety into this there will simply be too much information to remember.

As we have it now, it's more "these are all the ways you can use multithreading in Rust and at a high level, and just take our word that everything is thread safe". This by itself already fills up 50 minutes. We could potentially think about moving things out into a 30 min after dark lecture...

I think for the purposes of this lecture (and really for all of the lectures after lifetimes), we want to give more of a tutorial rather than explain why things are the way they are. I'm open to trying to add more things to this lecture, but I think we should focus on the foundational topics in the first half of the semester (which is really just making sure people understand ownership)

[jespiron]

Actually, I'm in support of reducing information. I feel like the current lecture is too much to digest, so I was working out how we can make it easier to digest.

As a student who had prior experience with parallelism but not in Rust, I thought it was fast. I feel like a student with no prior experience would be overwhelmed.

The main suggestions I have are

Slow down on earlier topics: Our current examples are great! I think we should take more time to step through them, enough that our audience can write things down. I took notes for each lecture (😄) but I barely wrote anything down for this since it was so fast. Namely, the code blocks take time to digest.

Removing a few topics: In exchange for slowing down on earlier topics, we can trim down on the latter half. The extra topics I was talking about, under "More Shared State Primitives" and "Even More Primitives"-- I'm leaning towards removing them in exchange for "See the book for more"

I wrote a WIP outline to identify topics we want to keep.

I hope this clarifies! My earlier comment about thread safety might have been distracting. It was a byproduct of working through the outline, but the main point I wanted to raise was simplifying the lecture.

[connortsui20]

Ah if that's the case then I completely agree, I would prefer to have a focus on the current first half as well