3 ms·
Prediction #3 is the only one which I can't see being interpreted as being reasonably accurate. Anybody care to explain why it might be correct?
by JDShu 14y ago
Prediction #3 is the only one which I can't see being interpreted as being reasonably accurate. Anybody care to explain why it might be correct?
- gizmo 14y ago10 years ago I wrote desktop software with UI threads, background worker threads, network layer threads and various helper threads you spawned on a whim. And so did everybody else. Back then the big innovation to multi-threaded programming was the use of RAII Mutexes[1] to avoid livelock/deadlock scenarios. Fast forward to today. We write complex software for the browser with Javascript front-ends that are completely asynchronous. On the server we have a share-nothing-architecture where hundreds of incoming requests are divided over independent workers. There is still complex multi-threading going on in the database and in the web browser, but most programmers don't have to deal with it anymore. The problem of locks and deadlocks is pretty much a responsibility of the operating system now, much like virtual memory and writing data to the filesystem. [1] http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...
- carbuncle 14y agoWe are doing more "multi-process" programming than "multi-threading". Our systems are designed to scale by increasing the number of processes performing the task at hand, more than having one process with multiple threads to increase concurrency. The programmers try not to think delegate the thread management to the OS, by using multiple processes and MQ in between.