Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teaching Concurrency (2009) [pdf]

research.microsoft.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Teaching Concurrency (2009) [pdf]

#31

Post by dogecoinbase »

argv_empty wrote: post #19
Const-me wrote: post #18

Earlier quoted context omitted.

> one of those is what actually happens No it’s not. If the heads aren’t moving in lockstep, what actually happens is you’ll extremely rarely have a moment of time when both locations are whole numbers. At one moment you have { head1loc=0, head2loc=4.17 }, head #1 reached the cell position on the tape, head #2 is still moving. After a while, you’ll have { head1loc=0.872, head2loc=5}, head #1 is on its way, head #2 re…

Even if a Turing machine were a physical object (I had thought you would be aware that it's not), either one of those moves completes before the other, or both complete simultaneously.

if a Turing machine were a physical object ... either one of those moves completes before the other, or both complete simultaneously.

...depending on how fast you're moving relative to the machine heads and in what direction. Simultaneity does not exist in the real world.

Re: Teaching Concurrency (2009) [pdf]

#32

Post by hcarvalhoalves »

Const-me wrote: post #9

When 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.

Same idea: https://www.factorio.com/

Re: Teaching Concurrency (2009) [pdf]

#33

Post by TickleSteve »

gohrt wrote: post #30
TickleSteve wrote: post #26

Earlier quoted context omitted.

if you are in an I/O bound situation, then yes, concurrency will allow you to exploit some parallelism. Otherwise, no. (and in general, people just throw concurrency at the problem instead of analysing whether they are in fact I/O bound or CPU bound). (Downvoted why??)

you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%

...and that is true.

When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?

Re: Teaching Concurrency (2009) [pdf]

#34

Post by TickleSteve »

srean wrote: post #29
TickleSteve wrote: post #27

Earlier quoted context omitted.

For CPU bound code, concurrency is pure overhead. For I/O bound code, concurrency can give you some benefit. ...but in general, people do not analyse this before throwing tasks at a problem.

> ...but in general, people do not analyse this before throwing tasks at a problem. Would that be just anecdotal ?

yes... in ~25 years in the business, over ~10 companies.

..and I can tell you that precisely none of them performed a correct analysis of a systems concurrency needs before 'designing' it.

A common artifact of this is far too many tasks.

Re: Teaching Concurrency (2009) [pdf]

#35

Post by srean »

TickleSteve wrote: post #34
srean wrote: post #29

Earlier quoted context omitted.

> ...but in general, people do not analyse this before throwing tasks at a problem. Would that be just anecdotal ?

yes... in ~25 years in the business, over ~10 companies. ..and I can tell you that precisely none of them performed a correct analysis of a systems concurrency needs before 'designing' it. A common artifact of this is far too many tasks.

I have seen egregious abuse of pre-emptive threads ... a lot. Abuse of green threads / fibres / coroutines ... not so much. I think one has to be a half decent programmer to be even aware those options.

Re: Teaching Concurrency (2009) [pdf]

#36

Post by VinzO »

TickleSteve wrote: post #4

I 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.

Do you have any suggestions of ressources to learn more on that specific topic. I am interested on ressources to learn more about when to use tasks or when it is better not to. Especially for embedded systems. I find now people use tasks for anything without having a real idea of the costs. I am also interested on when it is needed to use an embedded OS or when you could better do without one. Any kind of ressources, book, website etc is welcomed.

Re: Teaching Concurrency (2009) [pdf]

#37

Post by TickleSteve »

VinzO wrote: post #36
TickleSteve wrote: post #4

I 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.

Do you have any suggestions of ressources to learn more on that specific topic. I am interested on ressources to learn more about when to use tasks or when it is better not to. Especially for embedded systems. I find now people use tasks for anything without having a real idea of the costs. I am also interested on when it is needed to use an embedded OS or when you could better do without one. Any kind of ressources,…

Unfortunately, this is the type of real-world problem that isn't well taught (or even documented).

We are all taught from uni about how concurrency is implemented and most applications use concurrency as a design-tool to decompose a problem into its functions.

Unfortunately, this tends to produce a sub-optimal result as the inefficiencies become visible on small embedded/real-time systems.

Its difficult to give any general advice, but have a look at real-time analysis to get an idea of the real issues.... and don't blindly throw tasks at a problem when a simple superloop is more efficient/simple/maintainable.

Re: Teaching Concurrency (2009) [pdf]

#38

Post by arielb1 »

pron wrote: post #23
TickleSteve wrote: post #4

I 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.

> I think the first thing people should be taught about concurrency... is when not to use it. Concurrency is usually not a feature of the algorithm but a feature of the problem domain. If you have many requests coming in at the same time, all competing for a limited amount of computational resources -- you have concurrency. How you handle it is a different matter. You can decide to handle the requests one by one, but…

No. If the problem is computational resources, performance can't be increased by mere concurrency (while even completely deterministic STM-style parallelism would help).

Concurrency improves performance when a process accesses both the same computational resource and some other high-latency sharable resource.

Re: Teaching Concurrency (2009) [pdf]

#39

Post by arielb1 »

Const-me wrote: post #18
argv_empty wrote: post #17

Earlier quoted context omitted.

No, we just have different notions of system state. If we have a pair of, say, Turing machine heads on one tape that aren't necessarily moving in lockstep, I say that the system state is the tape contents, the two heads' locations, and the two heads' states. A transition for this system can be either or both heads moving either direction, overwriting the symbol they're pointing at, and changing its own internal state…

> one of those is what actually happens No it’s not. If the heads aren’t moving in lockstep, what actually happens is you’ll extremely rarely have a moment of time when both locations are whole numbers. At one moment you have { head1loc=0, head2loc=4.17 }, head #1 reached the cell position on the tape, head #2 is still moving. After a while, you’ll have { head1loc=0.872, head2loc=5}, head #1 is on its way, head #2 re…

Pick a reference frame. Sample the state of each CPU on its clock edge. Now you have a sequence of transitions.

The sequence is heavily non-deterministic, but that's life in a concurrent universe.

Re: Teaching Concurrency (2009) [pdf]

#40

Post by argv_empty »

arielb1 wrote: post #39
Const-me wrote: post #18

Earlier quoted context omitted.

> one of those is what actually happens No it’s not. If the heads aren’t moving in lockstep, what actually happens is you’ll extremely rarely have a moment of time when both locations are whole numbers. At one moment you have { head1loc=0, head2loc=4.17 }, head #1 reached the cell position on the tape, head #2 is still moving. After a while, you’ll have { head1loc=0.872, head2loc=5}, head #1 is on its way, head #2 re…

Pick a reference frame. Sample the state of each CPU on its clock edge. Now you have a sequence of transitions. The sequence is heavily non-deterministic, but that's life in a concurrent universe.

I'm not sure it's useful to try to discuss concurrency with someone who refuses to believe that a group of machines can be in a state (which is really the point of the article).
Post reply on HN