On Monday, 4 August 2014 at 18:22:47 UTC, Russel Winder via
Digitalmars-d-learn wrote:
Actually with CSP / actor model one can simply consider
long-running CPU computation as form of I/O an apply same
asynchronous design techniques. For example, have separate
dedicated thread running the computation and send input there
via message passing - respond message will act similar to I/O
notification from the OS.
Now you are on my territory :-) I have been banging on about
message
passing parallelism architectures for >25 years, but sadly
shared memory
multi-threading became the standard model for some totally
bizarre
reason. Probably everyone was taught they had to use all the
wonderful
OS implementation concurrency techniques in all their
applications
codes.
Well it is a territory not completely alien to me either ;) I am
less aware of academia research on topic though, just happen to
work in industry where it matters.
I think initial spread of multi-threading approach has happened
because it was so temptingly easy - no need to worry about
actually modelling the concurrency execution flow, blocking I/O
or scheduling; just write the code as usual and OS will take care
of it. But there is no place for magic in programming world in it
has fallen hard once network services started to scale.
Right now is the glorious moment when engineers are finally
starting to appreciate how previous academia research can help
them solve practical issues and all this good stuff goes
mainstream :)
There have been a number of PhDs trying to provide tools for
deciding
which parallelism architecture is best suited to a given
problem. Sadly
most of them have been ignored by the programming language
community at
large.
Doubt programming / engineering community will ever accept
research that states that choosing architecture can be done on
pure theoretical basis :) It simply contradicts too much all
daily experience which says that every concurrent application has
some unique traits to consider and only profiling can rule them
all.
