StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>No. Even as a rule of thumb, it's simply saying "it's hard to make them work." But event-driven frameworks are very much like event-driven simulation and various other things; the fact that it's hard in Javaworld isn't a fact about multithreading, but about the abstractions available in Java.</p> <p>In another environment, like Erlang, it's both fairly natural, are pretty robust.</p> <h3>Update</h3> <p>It still sounds like he has the wrong abstractions. I don't see anything inherent in the problem that forces a locking issue. The key, I think, come in here:</p> <blockquote> <p>Now, since we are using abstractions, we will naturally be doing locking separately within each abstraction. And unfortunately we have the classic lock ordering nightmare: we have two different kinds of activities going on that want to acquire locks in opposite orders. So deadlock is almost inevitable.</p> </blockquote> <p>So why is deadlock almost inevitable? Because two different kinds of activities are going on that want to acquire locks in opposite orders. And that is because "we will naturally be doing locking separately within each abstractions."</p> <p>In other words, he's chosen -- or had chosen for him by the environment -- abstractions that don't support his needs. It follows, he appears to claim, that thus there are no abstractions that would. I don't find this convincing. I'd start by examining two things:</p> <ul> <li>"<em>naturally</em> we will be doing locking separately within abstractions", and </li> <li>"we have events going on that want to acquire locks in opposite orders."</li> </ul> <p>In my experience, "naturally X" usually means "I haven't really looked for other options." And I very much doubt that the events want to acquire locks in opposite orders; yu get a lock, you do something, and you release it.</p> <p>The point is, he appears to be presenting the fact that he finds it hard to come up with a scheme that <em>does</em> work as a theorem to say that no scheme <em>can</em> work.</p> <p>Without a lot more details about the problem, it's hard to construct a counter-example, but as I said above, there are lots of examples of systems that have events going on every which way, asynchronously, from internal processes and GUIs, that manage to have many concurrent threads of control and don't deadlock. Erlang came to mind because one class of those problems, telephony, is the one for which Erlang was invented, and in fact those sorts of issues are <em>why</em> Erlang was invented.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload