TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

What makes concurrency so hard?

58 点作者 BerislavLopac大约 1 年前

15 条评论

Leftium大约 1 年前
Concepts from Functional Programming can be used to reduce the state space.<p>First, do as much work as possible in pure functions. Pure functions can safely be run in parallel, in any order because they do not have side-effects.<p>Then the side-effects can be applied. This code should be smaller&#x2F;simpler since any work that can be done in a pure function was already done.<p><a href="https:&#x2F;&#x2F;grokkingsimplicity.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;grokkingsimplicity.com&#x2F;</a> covers this topic in chapter 17: Coordinating timelines. The book even walks through a non-trivial example.
koliber大约 1 年前
I think it&#x27;s because people have a hard time seeing things from more than one perspective.<p>We live our days and react to things based on our perception. We think about our state. Few people think about how things look from another person&#x27;s perspective. Many people have a hard time really getting into someone else&#x27;s shoes.<p>With multithreading, people can reason about what one thread will do. They can also reason about what another thread will do. However, thinking about the various unexpected ways these threads could interact, and designing a protocol for those interactions to limit adverse behavior is something many people are bad at. One perspective at a time is OK. Holding 2 or more at once is tricky.
评论 #40064252 未加载
atemerev大约 1 年前
Actor model with preemption solves the entire thing like it was never a problem. Three axioms, one mechanism, puff, gone.<p>But for some strange reason, bona fide preemptive actors exist only in Erlang and derived languages (Elixir, Gleam, etc). All other actor model implementations are cooperative in some regard, which requires some thinking on blocking&#x2F;nonblocking code in actors etc. Only Erlang abstracts it all away.
评论 #40065484 未加载
mrkeen大约 1 年前
&gt; All means of making concurrency &#x27;easier&#x27; are concerned first and foremost with managing the state space.<p>&gt; Data mutations create new steps, which immutable data structures avoid by definition.<p>This is why I&#x27;ll already reach for immutability-first, and only mutate in special cases.
kazinator大约 1 年前
In the past, programmers opted for concurrency because creating a thread was the only way to get a continuation&#x2F;closure type entity, where you could nicely do everything in one tidy scope. So even the thread was preemptive, and thus particularly threatening, it was nicer to write the program.<p>Also, if you multiplex events onto a single thread, though you get some better guarantees about execution order than you do under preemptive threads, it is still chaotic. Events arrive in any order. Multiple state machines update their state in any order, and hit their important states in any order.<p>Data being chopped into frames arbitrarily scrambles things. The past million time the program read four bytes from the network socket, it got the entire 32 bit integer in one operation. Today, it didn&#x27;t notice that the read only returned 3 bytes.<p>Threads are exciting, especially to young programmers. Look, all you have to do is write little programs that do simple things in a loop, taking some messages here and replying there. Put them together, and the complex behavior of the application will somehow just emerge, as if by magic. And you don&#x27;t even have to document it anywhere; just document the simple things that the individual threads are doing!
评论 #40063039 未加载
评论 #40062083 未加载
jklowden大约 1 年前
Three words: Communicating Sequential Processes.
评论 #40062903 未加载
评论 #40061472 未加载
评论 #40062713 未加载
评论 #40061034 未加载
评论 #40062899 未加载
jemmyw大约 1 年前
I&#x27;d say it&#x27;s because it&#x27;s not obvious in the languages we use what is and is not an atomic operation. Different languages do provide different levels of protection by default as well, making it even harder to know what is and is not safe. Personally when I&#x27;m in a language that makes things obvious then it becomes easier to reason about. Rust helps, verbosly. I don&#x27;t have any problem in JavaScript because the runtime usually doesn&#x27;t allow for your own code to be running concurrently. Each way here has trade-offs.
评论 #40063623 未加载
eviks大约 1 年前
&gt; We do concurrent reasoning every time we drive a car!<p>&gt; More generally, some studies find that if you frame concurrent systems in human terms (&quot;meatspace modeling&quot;), people get quite good at finding the race conditions. &gt; So while concurrency might be difficult to reason about, I don&#x27;t think it&#x27;s because of a fault in our brains.<p>Indeed, when you drive a car you get rich input, unlike with concurrency where neither the design nor, even more importantly, execution, is presented to you in anything similarly comprehensible
评论 #40062829 未加载
dandanua大约 1 年前
People like to say that CSP solves everything. It&#x27;s not. In reality everything communicates through a shared memory. Take sound, for example. When a human speaks the shape of sound waves changes in the ear of another human. What&#x27;s happening is a write access to a shared resource. Another agent should process it accordingly. There is no magical &quot;onMessage&quot; in reality. CSP theory hides the fundamentals, thus it won&#x27;t be as fast as more basic primitives, combined correctly.
评论 #40063750 未加载
JohnCClarke大约 1 年前
FWIW: My hardware designer friends find software tediously limited because only one thing happens at a time.
neonsunset大约 1 年前
Mostly through either self-inflicted pain of languages that got its concurrency primitives wrong or ended up having it too complex to be useful before we arrived upon better ways.<p>Naturally, this is not to say the language designers were bad at it, far from it! It just took the benefit of the hindsight and time due to non-uniform knowledge propagation throughout the industry to nail them down as can be seen in Rust and C# in the form of async&#x2F;await and Futures+Tasks and CSP-style in the form of Elixir and Go.<p>Today, Rust makes it trivial (given the tradeoffs) to achieve such even in bare metal scenarios with custom executors, while C# offers zero-effort model for general purpose scenarios:<p><pre><code> using var http = new HttpClient(); var req1 = http.GetStringAsync(&quot;https:&#x2F;&#x2F;news.ycombinator.com&quot;); var req2 = http.GetStringAsync(&quot;https:&#x2F;&#x2F;lobste.rs&quot;); Console.WriteLine(string.Concat(await req1, await req2));</code></pre>
评论 #40066107 未加载
评论 #40082100 未加载
another2another大约 1 年前
&gt;What makes concurrency so hard?<p>AanTythinANgY canTI happeME!n
visarga大约 1 年前
state
datavirtue大约 1 年前
Emergence.
fire_lake大约 1 年前
Concurrency is not so hard if you have the right tools &#x2F; primitives:<p>- Monads with do-notation<p>- Atoms<p>- Immutable data structures
评论 #40061063 未加载