On 09/29/2015 10:22 AM, Thomas Hruska wrote:
On 9/29/2015 6:52 AM, Joe Watkins wrote:
We shouldn't reserve words on a whim ...
async/await doesn't solve any problems for multithreaded programming, at
all ... it solves problems for asynchronous programming, a different
concept ... let's not confuse the two ...
Agreed, the concepts are quite different, thought they can be related in
a way. More on that in a minute...
Actually, it does. Asynchronous and multithreaded programming are
attempts at solving the exact same problem: Simultaneously handling
multiple data streams in whatever form that takes whether that be
network, hard drive, random device XYZ, RAM, or even CPU. The former
says, "Let's wait until we can read or write and continue when we have
data." The latter says, "Let's read and write but let the OS handle
context switching to give the appearance of simultaneously handling
multiple data streams."
Actually, they *don't* attempt to solve the same problem (though some
problems can be solved with either). Concurrent programming (threads,
forks, or anything else that uses multiple execution contexts --
multiple program counters) has the purpose of enabling you to do two or
more things at once (as much as possible on the current CPU).
If you need to do two big ass math calculations, you can use
multithreading to do both at once. (I'll ignore instruction pipelining
restrictions and the context switching overhead curve for simplicity.)
In this example, asynchronous programming does nothing for us.
If you need to handle 10000 socket connections, threading isn't
practical with a thread-per-connection model. Here, async becomes useful
because the bottleneck is I/O, not CPU operations. Async programming
allows you to do other things instead of blocking the thread when doing
an I/O operation (... or a few other operation types).
So then, in summary, threads & multiprocessing enables you to do more
*work* simultaneously, while async **maximizes the usefulness of each
thread you have**. So using both is actually an incredibly good thing,
but they aren't the same nor accomplish the same thing. I hope what I
said made sense.
Now, on to async / await. :)
Async/await is both the best of and THE solution to both worlds. It
...
Yes. But not for the reason that I think you're thinking. Combining
concurrency with asynchronicity is the best of both worlds, and using
threads themselves in a non-blocking way with async / await (which are
strictly an async thing) is pretty powerful. Here's an example (in .NET):
static async void SlowAsync()
{
// Create a task which will be run in the threadpool
Task task = new Task(SlowAssOperation);
// Asynchronously wait (using the .NET event loop) for the thread to
complete
await task;
}
static void SlowAssOperation()
{
// Do something synchronous
Thread.Sleep(5000);
}
The fact that we can await something being run in a thread isn't a
property of threads, but a property of the .NET async event loop which
can listen for thread events without blocking.
Hope that clears some things up. Sorry for being long winded. :)
--
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
