3 ms·
just randomly looking at it.... http://cgi.di.uoa.gr/~mema/courses/mde518/papers/ousterhout-keynote.pdf http://cgi.di.uoa.gr/~mema/courses/mde518/papers/ouster
by keithnz 10y ago
just randomly looking at it.... http://cgi.di.uoa.gr/~mema/courses/mde518/papers/ousterhout-keynote.pdf http://cgi.di.uoa.gr/~mema/courses/mde518/papers/ousterhout-... seems like it's far too opinionated rather than educational, should keep to the job of explaining the problems of threads, not to put people off them by saying they are bad. That kind of thing can end up being burnt into a students mind. Better to promote other solutions, like abstractions over concurrency or languages with better abstractions. I'd hate to think we are training people to avoid concurrency when we are getting more and more multi processor systems
- simscitizen 10y agoThat's a classic paper to read for an operating systems class. Generally in an advanced OS class you read papers and discuss them critically. The value is in the discussion. Here is an example syllabus from Stanford's CS240: https://web.stanford.edu/class/cs240/old/sp2014/ https://web.stanford.edu/class/cs240/old/sp2014/. You can see that this paper is listed, along with a paper that states the opposite opinion ("Why Events are a Bad Idea").
- deleted 10y ago[deleted]
- bbcbasic 10y agoI think the paper is slightly too opinionated but remember it was 1995. No stm in haskell yet. No .net or javar threading libraries. (Ok... first version of java just released.) I wonder what nice abstractions existed then? Perhaps the papers view was balanced for its time. Also maybe context switching was super expensive on a 286 or whatever was available then. Windows and I believe Linux use message loops for UI and do fine. You can use callbacks for up bound stuff. Probably ok for a lot of applications.