Section 49: bounded, synchronous, unbounded, asynchronous

[njr0]

Although everything is fairly clear by the end of 49.2, 49.1 and 49.2 seems a bit confusing to me.

I've not come across the terms "bounded" and "unbounded" this context before, and had no real idea what it meant reading 49.1. There you say "asynchronous and unbounded".

In 49.2 you say "With bounded (synchronous) channels", which seems to imply that "bounded" is synonymous with "bounded". And indeed, the call is to sync_channel, which reinforces this idea. But when you run it, it looks like it only blocks when the channel fills.

This whole area's a nightmare because different parts of the concurrent/parallel/distributed world use these terms in different ways.

I think it would be clearer either:

• to omit "unbounded" from the 49.1
• or to explain the relationship between "unbounded" and "asynchronous" in 49.1
• or to swap 49.1 and 49.2, and to explain in the bounded/synchronous case that it only blocks when the channel fills and then in the unbounded cases that it never blocks (assuming that's true).

I think I would also not have the parenthesised "synchronous", which implies that these mean the same thing, whereas I think what you are saying is that all synchronous channels are bounded and all asynchronous channels are unbounded, but synchronous channels will only block when they fill.

[mgeisler]

• explain in the bounded/synchronous case that it only blocks when the channel fills and then in the unbounded cases that it never blocks (assuming that's true).

Yes, that is true! You understood things correctly: a synchronous channel will synchronize two threads when it is full. The synchronization means that each send will be matched up with a corresponding recv. You are exactly correct that this only happens when the channel is full — until then a mpsc::sync_channel() behaves like the ever-growing mpsc::channel().

[njr0]

Cool.

Will just mention in a somewhere random place, that's probably the end of my feedback on the course (though I'll keep following the issues, etc., and happy to interact). I've done all the main stuff and the concurrency section, and I don't really do embedded stuff or Android. (I'd do an iOS—or MacOS—day if you put one together, but I realise those might be a lower priority for Google!)

Thanks to everyone who put the course together, and especially to the people who've responded (and positively!) to my feedback and issues and things. (Sorry about those dodgy pull requests!)

I think the course is a really useful resource and I'm happy you've made it available. Obviously, I managed to get through it without an instructor, and I think with the tweaks you've already made, and the others I've suggested, it's quite reasonable to think people can do the main bit and (if they've worked with concurrency/threads before) the concurrency bit on their own, though I'm sure a suitable instructor would add value.