various edits to Concurrency chapter #248

Be-ing · 2025-02-21T05:12:59Z

Not much new content or changed meanings; mostly rewriting in clearer language

nrc

Thanks! Lots of good changes

nrc · 2025-02-27T22:30:06Z

src/part-guide/concurrency.md

@@ -1,12 +1,12 @@
 # Concurrent programming

-The goal of this chapter is to give you a high-level idea of how async concurrency works and how it is different from concurrency with threads. I think it is important to have a good mental model of what is going on before getting in to the practicalities, but if you're the kind of person who likes to see some real code first, you might like to read the next chapter or two and then come back to this one.
+The goal of this chapter is to give you a high-level idea of how async concurrency works and how it is different from concurrency with threads. Forming a good mental model of what is going on will help before getting in to the practicalities. If you're the kind of person who likes to see some real code first, you might like to read the next chapter or two and then come back to this one.


I think the first change is fine, but prefer to leave the 'but' since the last clause/sentence is in opposition to the previous one

nrc · 2025-02-27T22:31:34Z

src/part-guide/concurrency.md


 We'll start with some motivation, then cover [sequential programming](#sequential-execution), [programming with threads or processes](#processes-and-threads), and then [async programming](#async-programming). The chapter finishes with a section on [concurrency and parallelism](#concurrency-and-parallelism).

 Users want their computers to do multiple things. Sometimes users want to do those things at the same time (e.g., be listening to a music app at the same time as typing in their editor). Sometimes doing multiple tasks at the same time is more efficient (e.g., getting some work done in the editor while a large file downloads). Sometimes there are multiple users wanting to use a single computer at the same time (e.g., multiple clients connected to a server).

-To give a lower-level example, a music program might need to keep playing music while the user interacts with the user interface (UI). To 'keep playing music', it might need to stream music data from the server, process that data from one format to another, and send the processed data to the computer's audio system via the operating system (OS). For the user, it might need to send and receive data or commands to the server in response to the user instructions, it might need to send signals to the subsystem playing music (e.g., if the user changes track or pauses), it might need to update the graphical display (e.g., highlighting a button or changing the track name), and it must keep the mouse cursor or text inputs responsive while doing all of the above.
+To give a lower-level example, a music program might need to keep playing music while the user interacts with the user interface (UI). To 'keep playing music', it might need to stream music data from the server, process that data from one format to another, and send the processed data to the computer's audio system via the operating system (OS). For the user interface, it might need to send and receive data to the server in response to the user instructions; it might need to send signals to the subsystem playing music (e.g., if the user changes track or pauses); it might need to update the graphical display (e.g., highlighting a button or changing the track name); and it must keep the mouse cursor or text inputs responsive while doing all of the above.


Why remove 'commands' here?

Because the sentence is really long and I don't think "or commands" adds much

nrc · 2025-02-27T22:34:15Z

src/part-guide/concurrency.md

@@ -22,7 +22,7 @@ do_another_thing();

 Each statement is completed before the next one starts[^obs1]. Nothing happens in between those statements[^obs2]. This might sound trivial but it is a really useful property for reasoning about our code. However, it also means we waste a lot of time. In the above example, while we're waiting for `println!("hello!")` to happen, we could have executed `do_another_thing()`. Perhaps we could even have executed all three statements at the same time.

-Even where IO[^io-def] happens (printing using `println!` is IO - it is outputting text to the console via a call to the OS), the program will wait for the IO to complete[^io-complete] before executing the next statement. Waiting for IO to complete before continuing with execution *blocks* the program from making other progress. Blocking IO is the easiest kind of IO to use, implement, and reason about, but it is also the least efficient - in a sequential world, the program can do nothing while it waits for the IO to complete.
+Even where IO[^io-def] happens (printing using `println!` is IO - it is outputting text to the console via a call to the OS), the program will wait for the IO to complete[^io-complete] before executing the next statement. Waiting for IO to complete before continuing with execution *blocks* the program from progressing with anything else. Blocking IO is the easiest kind of IO to use, implement, and reason about, but it is also the least efficient. In a sequential world, the program can do nothing while it waits for the IO to complete.


I prefer the 'making progress' formulation to 'progressing', I feel like 'making progress' in execution is a known idiom (maybe close to a term of art) in the concurrency literature. For the punctuation change, the second clause is an implication of the first so I think it should be either a colon or dash rather than a full stop.

nrc · 2025-02-27T22:36:50Z

src/part-guide/concurrency.md


-A thread can also choose to pause itself by calling a `sleep` function, usually with a timeout. In this case the OS pauses the thread at the threads own request. Similar to pausing due to pre-emption or IO, the OS will wake the thread up again later (after the timeout) to continue execution.
+A thread can also choose to pause itself by calling a [`sleep`](https://doc.rust-lang.org/stable/std/thread/fn.sleep.html) function, usually with a timeout. In this case the OS pauses the thread at the thread's own request. Similar to pausing due to pre-emption or IO, the OS will wake the thread up again later (after the timeout) to continue execution.


I prefer not to link to the docs here since I'm talking about a generic idea of sleeping rather than a specific implementation.

nrc · 2025-02-27T22:38:39Z

src/part-guide/concurrency.md


-Finally, note that some hardware or OSs do not support processes or threads, this is more likely in the embedded world.
+Finally, note that some hardware or OSs do not support processes or threads. In the embedded world, there is no operating system, so there is nothing to provide processes or threads.[^rtos]


I prefer the first formulation here since this is not meant to be specific to Rust and as you note some embedded OSs do have threads.

nrc · 2025-02-27T22:42:06Z

src/part-guide/concurrency.md


 [^proc-program]: from the user's perspective, a single program may include multiple processes, but from the OS's perspective each process is a separate program.
 [^shmem]: Some OSs do support sharing memory between processes, but using it requires special treatment and most memory is not shared.
 [^sched]: Exactly how the OS chooses which thread to run and for how long (and on which core), is a key part of scheduling. There are many options, both high-level strategies and options to configure those strategies. Making good choices here is crucial for good performance, but it is complicated and we won't dig into it here.
-[^busywait]: There's another option which is that the thread can *busy wait* by just spinning in a loop until the IO is finished. This is not very efficient since other threads won't get to run and is uncommon in most modern systems. You may come across it in the implementations of locks or in very simple embedded systems.
-
+[^busywait]: There's another option which is that the thread can *busy wait* by just spinning in a loop until the IO is finished. This is not very efficient, both in terms of electrical energy needed by the CPU and throughput since other threads won't get to run. Busy waiting is uncommon in most modern systems, though you may come across it in the implementations of locks or in very simple embedded systems.


I think busy waiting can be efficient in terms of throughput which is why it is used :-) I suspect it can be more efficient in terms of energy too since it avoids a context switch. I prefer to keep the use of 'efficient' vague here, but if you strongly prefer to clarify, then I guess saying it "sounds inefficient, but..." or "can be inefficient at times but... " might be better?

nrc · 2025-02-27T22:43:50Z

src/part-guide/concurrency.md


 From the perspective of the whole system, blocking IO in a concurrent system with threads and non-blocking IO in an async concurrent system are similar. In both cases, IO takes time and other work gets done while the IO is happening:
- With threads, the thread doing IO requests IO from the OS, the thread is paused by the OS, other threads get work done, and when the IO is done, the OS wakes up the thread so it can continue execution with the result of the IO.
+- With threads, the thread doing IO requests IO from the OS, then the thread gets paused by the OS, other threads get work done, and when the IO is done, the OS wakes up the first thread so it can continue execution with the result of the IO.


I prefer 'is' to 'gets' the latter sounds a bit indirect or informal

nrc · 2025-02-27T22:46:31Z

src/part-guide/concurrency.md


 [^p-not-c]: Can computation be parallel but not concurrent? Sort of but not really. Imagine two tasks (a and b) which consist of one sub-task each (1 and 2 belonging to a and b, respectively). By the use of synchronisation, we can't start sub-task 2 until sub-task 1 is complete and task a has to wait for sub-task 2 to complete until it is complete. Now a and b run on different processors. If we look at the tasks as black boxes, we can say they are running in parallel, but in a sense they are not concurrent because their ordering is fully determined. However, if we look at the sub-tasks we can see that they are neither parallel or concurrent.
-
-[^turon]: Which I think is due to Aaron Turon and is reflected in some of the design of Rust's standard library, e.g., in the [available_parallelism](https://doc.rust-lang.org/std/thread/fn.available_parallelism.html) function.
+[^std]: This framing is used in Rust's [standard library and documentation](https://doc.rust-lang.org/std/thread/fn.available_parallelism.html).


Why make this change?

The original wording made a claim with uncertainty without citing a specific source, making it difficult to verify. Looking at this again, I'm wondering if this footnote really adds much? Maybe just delete it?

Fair enough, I think the source (and to remove the uncertainty) would be Aaron's thesis. I thought it was an interesting bit of history, but you're probably right that it doesn't add much and removing the footnote is fine.

Be-ing force-pushed the concurrency branch from 688f0e0 to 1318a2d Compare February 21, 2025 05:13

various edits to Concurrency chapter

4080d2b

Not much new content or changed meanings; mostly rewriting in clearer language

Be-ing force-pushed the concurrency branch from 1318a2d to 4080d2b Compare February 21, 2025 05:19

nrc reviewed Feb 27, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

various edits to Concurrency chapter #248

various edits to Concurrency chapter #248

Be-ing commented Feb 21, 2025

nrc left a comment

nrc Feb 27, 2025

nrc Feb 27, 2025

Be-ing Feb 27, 2025

nrc Feb 27, 2025

nrc Feb 27, 2025

nrc Feb 27, 2025

nrc Feb 27, 2025

nrc Feb 27, 2025

nrc Feb 27, 2025

Be-ing Feb 27, 2025

nrc Mar 2, 2025


		A thread can also choose to pause itself by calling a `sleep` function, usually with a timeout. In this case the OS pauses the thread at the threads own request. Similar to pausing due to pre-emption or IO, the OS will wake the thread up again later (after the timeout) to continue execution.
		A thread can also choose to pause itself by calling a [`sleep`](https://doc.rust-lang.org/stable/std/thread/fn.sleep.html) function, usually with a timeout. In this case the OS pauses the thread at the thread's own request. Similar to pausing due to pre-emption or IO, the OS will wake the thread up again later (after the timeout) to continue execution.


		Finally, note that some hardware or OSs do not support processes or threads, this is more likely in the embedded world.
		Finally, note that some hardware or OSs do not support processes or threads. In the embedded world, there is no operating system, so there is nothing to provide processes or threads.[^rtos]

various edits to Concurrency chapter #248

Are you sure you want to change the base?

various edits to Concurrency chapter #248

Conversation

Be-ing commented Feb 21, 2025

nrc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment