The free lunch is over: a fundamental turn toward concurrency in software (2005)
1–10 of 101 posts
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#2People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'.
I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#3People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
[deleted]
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#4People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
> I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
I think it's the tooling. Rust's modelling of concurrency using it's type system (the Send and Sync traits) make concurrency pretty straightforward for most use cases. You still have to be super-careful when creating the core abstractions using unsafe code, but once you have them they can easily be shared as libraries and it's a compile error to violate the invariants. And this means that most projects will never have to write the hard parts themselves and get concurrency for close to free.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#5People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
I will go with lack of education as main issue.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#6People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
> concurrency is still widely regarded as 'too hard'.
The question is: by whom?
High performance software, like game engines, DAWs or video editors, has been heavily multithreaded for a while now.
Maybe it's consumer or business software that could profit from more multithreading? I don't know, because I don't work in those areas.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#7People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
I will go with lack of education as main issue.
Memory models are subtle. Temporal reasoning in context of h/w, e.g. multi-core coherence, and language runtime MM is non-trivial. So there is a baseline level of difficulty baked into the domain. Education certainly is necessary, but here can only inform of what needs to be considered, known pitfalls, patterns of concurrency, etc.
As to OP, well it better be viable, because we certainly need to deal with it. So better tooling and conventions encapsulated in expert developed libraries. The education level required will naturally fall into the categories for those who will develop the tools/libraries, and those that will use them.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#8People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
I will go with lack of education as main issue.
Lack of real need I think.
Most of the computers in the world are either dedicated embedded controllers or end user devices. Concurrency in embedded controllers is pretty much an ordinary thing and has been since the days of the 6502/Z80/8080. For end user devices the kind of concurrency that matters to the end user is also not extraordinary, plenty of things happen in the background when one is browsing, word processing, listening to music, etc.
So that leaves concurrency inside applications and that just isn't something that affects most of the end users. There really isn't much for a word processor to actually do while the user is thinking about which key to press so it can do those few things that there was not time for during the keypress.
Mostly what is needed is more efficient code. Niklaus Wirth was complaining that code was getting slower more quickly than hardware was getting faster forty years in 1995 and it seems that he is still right.
See https://blog.frantovo.cz/s/1576/Niklaus%20Wirth%20-%20A%20Pl...
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#9If only GPUs were more common and easier to work with.
Re: The free lunch is over: a fundamental turn toward concurrency in software (2005)
#10People having been saying this for decades and while it's true, concurrency is still widely regarded as 'too hard'. I'm not sure if this is justified (e.g. concurrency is inherently too hard to be viable), or due to the lack of tooling/conventions/education.
> concurrency is still widely regarded as 'too hard'. The question is: by whom? High performance software, like game engines, DAWs or video editors, has been heavily multithreaded for a while now. Maybe it's consumer or business software that could profit from more multithreading? I don't know, because I don't work in those areas.
> The question is: by whom?
I do feel similarly, even though I wouldn't classify myself as a great engineer.
I've been writing concurrent software in managed languages, such as Java and C#[0], from the very beginning of my career, up until today. The level of multithreading has varied, but it's always been there. For anything beyond basic CRUD it pretty much becomes a requirement, both on desktop and on the web[1].
That doesn't mean I've never had a tricky race condition to debug (and, yes, they're hard to debug) during development, but I've never shipped a concurrency related bug to production[2].
The canonical examples of concurrency gone wrong are things like giving somebody a deadly radiation dose from a medical device but, in terms of serious software bugs, I do wonder how common concurrency bugs are relative to other types of bug, and whether they're really more serious in aggregate than those other types of bug.
[0] Admittedly these languages make it a lot easier to avoid shooting yourself in the foot than C and C++ do.
[1] Also worth bearing in mind that an inherent property of most, if not all, distributed software is that it's also concurrent: the moment you have multiple processes running indepedently or interdependently you also usually have a concurrent system, with the potential for "distributed race conditions" to occur. I.e., if you have a SPA that also has a non-trivial back-end, you have a concurrent system - just spread across different processes, generally on different machines.
[2] In the context of in-process concurrency. Distributed concurrency is a different matter.