Teaching Concurrency (2009) [pdf]
research.microsoft.com
Teaching Concurrency (2009) [pdf]
1–10 of 47 posts
Re: Teaching Concurrency (2009) [pdf]
#2The only actionable advice in here for someone tasked with developing a curriculum for teaching concurrency is to make sure the prerequisite courses instill the idea of computation as a sequence of state transitions.
Re: Teaching Concurrency (2009) [pdf]
#3[deleted]
Re: Teaching Concurrency (2009) [pdf]
#4I think the first thing people should be taught about concurrency... is when not to use it.
Concurrency can result in increased maintenance costs and complexity.
Concurrency is also not more efficient on a single core.
Concurrency can help with latency and response time.
In embedded systems in particular, there is an over-use of concurrency which often results in bloated, complex code.
Re: Teaching Concurrency (2009) [pdf]
#5I think the first thing people should be taught about concurrency... is when not to use it. Concurrency can result in increased maintenance costs and complexity. Concurrency is also not more efficient on a single core. Concurrency can help with latency and response time. In embedded systems in particular, there is an over-use of concurrency which often results in bloated, complex code.
> Concurrency is also not more efficient on a single core.
This isn't a hard and fast rule. There is overhead to parallelism.
Re: Teaching Concurrency (2009) [pdf]
#6I think the first thing people should be taught about concurrency... is when not to use it. Concurrency can result in increased maintenance costs and complexity. Concurrency is also not more efficient on a single core. Concurrency can help with latency and response time. In embedded systems in particular, there is an over-use of concurrency which often results in bloated, complex code.
[deleted]
Re: Teaching Concurrency (2009) [pdf]
#7I think the first thing people should be taught about concurrency... is when not to use it. Concurrency can result in increased maintenance costs and complexity. Concurrency is also not more efficient on a single core. Concurrency can help with latency and response time. In embedded systems in particular, there is an over-use of concurrency which often results in bloated, complex code.
The next thing they should be taught is that even if an existing serial implementation can be made more efficient using concurrency, that doesn't mean it should be. That should be followed quickly by teaching that concurrency should be implemented over the smallest possible surface of the code.
Re: Teaching Concurrency (2009) [pdf]
#8I think the first thing people should be taught about concurrency... is when not to use it. Concurrency can result in increased maintenance costs and complexity. Concurrency is also not more efficient on a single core. Concurrency can help with latency and response time. In embedded systems in particular, there is an over-use of concurrency which often results in bloated, complex code.
> Concurrency is also not more efficient on a single core. This isn't a hard and fast rule. There is overhead to parallelism.
And if you step out all the parallelism from your concurrency runtime, you get rid of a big chunk of the overhead. But even with purely cooperative single-threaded multitasking, there's still some overhead vs "ordinary" strictly serial code.
Re: Teaching Concurrency (2009) [pdf]
#9When I was a kid, I loved playing transport tycoon deluxe videogame.
When I grew up to be a programmer, never had much problems with concurrent stuff.
IMO designing concurrent programs is conceptually similar to building complex high-throughput low latency railway networks in the game.
Re: Teaching Concurrency (2009) [pdf]
#10The only actionable advice in here for someone tasked with developing a curriculum for teaching concurrency is to make sure the prerequisite courses instill the idea of computation as a sequence of state transitions.
“Sequence of state transitions” implies you can order them by time. Generally, various state transitions happen in parallel, their relative order is undefined even on an SMP system.
You can serialize the transitions if you want, but that usually costs performance. This is especially true for distributed parallel computing, where the state is also distributed.