11 ms·
15 Years of Concurrency
- relics443 10y agoThis looks like it's gonna be a long, interesting read. I better save up my bathroom time...
- okreallywtf 10y agoNot sure why you got down voted, I feel the same way. I read what I was sure was 3/4 of it only to realize it was about 1/8 but I'm definitely going to save it and finish. I'm slightly (very?) jealous that I am not so passionate about any part of software as the author. I am interested in lots of areas but no one piece of the puzzle draws me and its bittersweet sometimes to read the thoughts of someone who seems so passionate about their field.
- garrettgrimsley 10y ago>Not sure why you got down voted Because the comment adds nothing to the conversation.
- module0000 10y agoIt adds humor, and we like that sort of thing on HN
- scott_s 10y agoPost that only try to be funny tend to be downvoted on HN. We try to avoid reddit style threads where people just post one-liners.
- tomcam 10y ago> I better save up my bathroom time Unsure about implementation details
- victorcase 10y agoHey another article at YC frontpage about saying "DO NOT MESS WITH STATE" to scale; "Shared-memory multithreading really isn’t the future, we thought, and notably absent from all of my prior work was fixing this problem." I'm thinking about.. Immutability is the way to scale complex systems? Every system can be implemented as immutable by definition? We need to look to build new data structures - like Tries - to be Immutable-friendly? When Immutability doesn't worth it?
- Bahamut 10y agoPerformance - immutability comes at a high cost sometimes.
- VodkaHaze 10y agoEspecially when memory constrained
- victorcase 10y agoOk in the context of - critical - constrained memory I understand; However do you agree that is more easy to solve memory (buying new hardware) than handle with race condition? kkkk Then, Maybe we need to think about optimize our daily data structures.. I have following a few papers about this.. e.g: http://dl.acm.org/citation.cfm?id=2658763 http://dl.acm.org/citation.cfm?id=2658763 http://dl.acm.org/citation.cfm?id=2993251 http://dl.acm.org/citation.cfm?id=2993251
- jandrese 10y agoIt's easy to buy memory, but hard to buy L2/L3 cache. The whole point of the exercise is to scale more easily on multicore architectures, but it's no good if you blow out the cache thousands of times per second and bottleneck the system on memory accesses.
- AstralStorm 10y ago
- scribu 10y agoFor anyone else wondering what "Midori" is, it looks like it was an internal Microsoft research project: http://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/
- honkhonkpants 10y agoI've been reading these but it's become apparent that the author lives in a universe parallel to mine. I remember reading that in most languages "A null dereference or out-of-bounds array access is treated the same way as a network connectivity problem or parsing error" and scratching my head, because while I know some languages are like that (Java) there are others were a null dereference and the failure to establish a network connection have radically different effects (C++). At another point discussing error handling he says "This leads us to a beautiful sweet spot. It does suffer from the performance problems I mentioned earlier, but does very well on all other dimensions." so the author's sweet spot is a spot with poor performance, which also put me off because his articles all talk about performance but never concretely (in terms of nanoseconds). Anyway it's an interesting, if long, series but most of the interest for me has been in reading things from a very different perspective from the one I hear at work every day.
- Locke1689 10y agoI'm not really clear what this comment implies? What system do you work with that doesn't have null pointers but also cares about eliminating as many fine-grained locks as possible?
- nickpsecurity 10y agoWeird thing is that the inspirations didnt factor in only commercially-depolyed schemes for safe concurrency: Ada's and Eiffel SCOOP. The SCOOP model was even ported to Java at one point.
- jwatte 10y agoErlang CSP is also commercially deployed and safe.
- deleted 10y ago[deleted]
- krat0sprakhar 10y agoTo note: > Out of the bunch, Rust has impressed me the most. They have delivered on much of what we set out to deliver with Midori, but actually shipped it (whereas we did not). My hat goes off to that team, seriously, because I know first hand what hard, hard, hard work this level of type system hacking is.
- jacquesgt 10y agoBut see also: > In particular, I’m still conflicted about whether all those type system extensions were warranted. Certainly immutability helped with things far beyond safe concurrency. And so did the side-effect annotations, as they commonly helped to root out bugs caused by unintended side-effects. The future for our industry is a massively distributed one, however, where you want simple individual components composed into a larger fabric. In this world, individual nodes are less “precious”, and arguably the correctness of the overall orchestration will become far more important. I do think this points to a more Go-like approach, with a focus on the RPC mechanisms connecting disparate pieces.
- kibwen 10y agoI don't think this is incompatible with Rust's goal, which is to bring safety to the sort of low-level domain where C is currently dominant and systems can't afford to be structured as isolated nodes communicating only via RPC. In contrast, Midori was aimed at a higher-level general-purpose domain, like Go (and Erlang, too, which is even better than Go at the "cluster of nodes" approach, yet doesn't have a type system at all).
- k__ 10y agoCould it be, that many desicions for Rust have been made to make it more appealing to C devs? Like, opting out of purity annotations or forced immutability? I'm not saying these desicions are good or bad, I don't know much about system programming. But I often ask myself what the main motivators for a language are.
- 10y ago
- signa11 10y agofrom the article: So, we made some: Isolation is paramount, and we will embrace it wherever possible. Message passing will connect many such isolated parties through strongly typed RPC interfaces. Namely, inside of a process, there exists a single message loop, and, by default, no extra parallelism. A “promises-like” programming model will be first class so that: Synchronous blocking is disallowed. All asynchronous activity in the system is explicit. Sophsiticated (sic) coordination patterns are possible without resorting to locks and events. with the exception of trying concurrency primitives on heavy-weight os provided processes, this looks like recreation/rediscovering of erlang primitives once again :) would one be chastisized for wagering that erlang is the lisp of concurrency world ? edit-001: slight clarification (hopefully)
- brightball 10y agoEvery time I read about concurrency in other languages I see them trying to become Erlang but without the core design decisions that make Erlang works. Always reminds me of this quote: "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." - Robert Vriding
- pjmlp 10y agoThe problem is that Erlang is only good a network communication and parallel programming, which is of course to be expected, given the language design goals. The problem is when one tries to make a general purpose solution out of that design. For example, how would Erlang look like in GPGPU programming, video/audio codecs, graphics programming, GUI,...
- signa11 10y ago> The problem is when one tries to make a general purpose solution out of that design. yup. go(lang) / rust seems to be exploring some ideas with an almost similar approach, but not _solely_ focussed on n/w programming. are there other languages out there as well ? and a slightly open ended question as well: in your opinion, do you think a language needs to implement a complete runtime (similar to erlang) with it's own 'process' abstraction, scheduler, i/o etc. etc. to provide concurrency support ?
- deleted 10y ago[deleted]
- amelius 10y ago15 Years of Concurrency ... and now we're all using JavaScript, which has a single-thread model, and doesn't allow cross-thread structural sharing of data structures (without going through a number of hoops).
- pkolaczk 10y agoWhich ironically, is a model with probably best performance and scaling characteristics. If you want high performance, you should avoid sharing mutable stuff as much as possible.
- donatj 10y agoI disagree. Play with Go's go routine and channels and see how easily you can spread a simple or complex job across 16 cores, and then bring that data all back together. JS has nothing on that.
- djtriptych 10y agoPretty good CSP implementation in clojurescript though, which compiles down to JS.
- danarmak 10y agoThe bigger problem is that Javascript disallows (or at least, browsers don't currently provide) efficient sharing of immutable values between threads/workers. Because JS has no notion of immutability, sharing is done via copying - but what's worse, copying via full-blown serialization, not just in-memory blitting or COW. At least, that was the state of things when I last checked a year ago.
- maxpolun 10y agoModern JS does allow you to send large buffers from one worker to another with just a pointer copy (because it stops being accessible from the sender).
- agentgt 10y agoOn Joe Duffy's profile there is what I thought to be a hexadecimal: 284d69f1cb I tried converting it to ascii and decimal and nothing interesting came out. Anyone know what that is? Maybe a key signature?
- ludwigvan 10y agoProbably a part of the hash of the first Git commit of his new project.
- agentgt 10y agoAlthough distributed programming is different than concurrency (albeit one I suppose could argue) I was hoping for some mentioning of Join Calculus. Particularly Polyphonic C# [1] (given Duffy's MS background). I have been meaning to re-investigate Join Calculus (the last time I did was in OCaml a long time ago) and to why it never really took off. Some programming patterns can be found here: https://en.wikipedia.org/wiki/Join-pattern https://en.wikipedia.org/wiki/Join-pattern [1]: https://en.wikipedia.org/wiki/Polyphonic_C_Sharp https://en.wikipedia.org/wiki/Polyphonic_C_Sharp
- sriram_malhar 10y agoTrue. Both polyphonic C# and JoCaml were lovely projects.
- romaniv 10y agoI've recently stumbled upon a very interesting paper about concurrency. Naming and Synchronization in a Decentralized Computer System: http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-205.pdf http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-20... It's written in 1978, but if I interpret it correctly, it's still conceptually ahead of everything mentioned in the article (the closest thing being STM). Anyone else here seen it?
- pjmlp 10y agoNo, but thanks for bringing it up, it appears an interesting read.
- michaelsbradley 10y agoThis is a fantastic write-up. It was back in 2011 that I first started wrapping my head around the complexities of concurrent programming. Even in single-threaded environments, such as a JavaScript processes, concurrency woes can escalate quickly in terms of the non-determinism introduced by asynchronous operations (timers, I/O) and their callbacks. My trying to understand and deal with those complexities resulted in an exploration of functional-reactive programming concepts, which in turn led me to make a "deeper dive" into computer programming language design and various computer science topics. Concurrency is still the CS topic that makes my ears perk up the most.
- sriram_malhar 10y agoOne of the things that this blog ought to have clearly mentioned is that all this business about static analysis, ownership types, read-write annotations, purity, immutability and all that is due to a simple conflation of two axes that ought to be orthogonal: mutation and aliasing. This is what Rust gets right: you can have an object be mutable (in which case you have only one pointer to it), or you can multiply alias pointers, all of which can only read the object. The type system enforces a static RW locking scheme in a manner of speaking; it ensures that only one of those capabilities is available at any one point in time. In other words, Rust ensures that mutation by itself is not a problem, that passing mutable structures between threads is statically checked for safety. You don't _have_ to make an object immutable in order to share safely by reference. --------------- It'd have been nice to hear about the "P" language, also from MSR (https://www.microsoft.com/en-us/research/publication/p-safe-asynchronous-event-driven-programming/ https://www.microsoft.com/en-us/research/publication/p-safe-...). No pointers, just value types, communicating state machines, produces model-checkable code. What's not to like?
- pjmlp 10y ago> It'd have been nice to hear about the "P" language And already used in production, even if in a small use case.