ImpossibleThreading
From APIDesign
(→Don't Say It is Impossible) |
(→NetBeans Threading) |
||
| Line 5: | Line 5: | ||
Once upon a time, probably slightly after year 2000, [[NetBeans]] had enormous problems with [[deadlock]]s. Not surprisingly. [[Swing]] is single-threaded, but we were running a lot of tasks on background and they were competing for resources (like the [[Swing]] dispatch thread, or their own locks, etc.). My boss asked me to fix this. | Once upon a time, probably slightly after year 2000, [[NetBeans]] had enormous problems with [[deadlock]]s. Not surprisingly. [[Swing]] is single-threaded, but we were running a lot of tasks on background and they were competing for resources (like the [[Swing]] dispatch thread, or their own locks, etc.). My boss asked me to fix this. | ||
| - | Yes, [[I]] was [[impossible|the expert]] - I knew about [[deadlock conditions]] and was aware that it is enough to make sure just one of them is not true and we | + | Yes, [[I]] was [[impossible|the expert]] - I knew about [[deadlock conditions]] and was aware that it is enough to make sure just one of them is not true and we would have a [[deadlock]]-free system. Yet I also remembered my lectures from [[MatFyz]] where we were informed that there is no coherent theory to drive development of [[deadlock]]-free system. Especially if you have a system composed from independent [[module]]s, they may be [[deadlock]]-free themselves, but when you assemble them together a deadlock can still appear. |
== Is It [[Impossible]]? == | == Is It [[Impossible]]? == | ||
Revision as of 21:24, 2 January 2015
Another story about problems with explaining that something is impossible is here. This time it touches my own experience with threading.
Contents |
NetBeans Threading
Once upon a time, probably slightly after year 2000, NetBeans had enormous problems with deadlocks. Not surprisingly. Swing is single-threaded, but we were running a lot of tasks on background and they were competing for resources (like the Swing dispatch thread, or their own locks, etc.). My boss asked me to fix this.
Yes, I was the expert - I knew about deadlock conditions and was aware that it is enough to make sure just one of them is not true and we would have a deadlock-free system. Yet I also remembered my lectures from MatFyz where we were informed that there is no coherent theory to drive development of deadlock-free system. Especially if you have a system composed from independent modules, they may be deadlock-free themselves, but when you assemble them together a deadlock can still appear.
Is It Impossible?
I did what experts do. I said: "It's impossible!" and explained my reasoning. Looking back and reminding myself of the finite-state automaton story, it was no surprise my boss didn't listen. I lost my credibility as an expert and he selected somebody else to make NetBeans deadlock free!
As a result we got a detailed write up describing the state of locking at that time (it was really bad) and suggestions to modify state under write-lock and deliver events under read-lock. For a while it seemed to work OK (it takes a while before people report deadlocks in new code), but then it turned out this style is actually a source of major and hard to solve deadlocks and long pauses when rendering the UI (a typical syndrome of designing a "solution" of something that is impossible to be solved).
Seeking the Flaws
Again I acted as experts do, I tried to find out why the offered solution is completely stupid. Maybe I was just too proud, or maybe I just didn't want to rewrite most of the NetBeans APIs (and change them incompatibly) to a new threading scheme without guaranteed result (those who follow this web may know I honour backward compatibility a lot).
As such I seeked for ways to eliminate our deadlocks - but not thanks to a new and unproven master plan, but with as little changes as possible (e.g. trying to not shake the Amoeba of NetBeans needlessly). At the end I learned how to simulate any deadlock in a unit test (see FlowControllingTest for details) and only then fix it. As a result the number of deadlocks in critical areas started to decrease. It took few years (and also a lay-off of my former manager) before it got clear that the threading cannot be fixed by a vision (which I had denied to provide), but rather a hard work (as I had shown).
Don't Say It is Impossible
The expert (e.g. me) was again right. However, given the few years of struggling I had to go through, I'd have reacted differently to the initial question of my manager: rather than saying fighting deadlocks is impossible, I'd say we need to create a process to help our developers to fight with deadlocks (e.g. you have to write a test before fixing a deadlock). The result would be the same and I would have taken less suffering. Moreover such answer might have suited my manager more, as he was famous for mixing technical and human factors by saying: we have a technical issue, we need somebody to ...."
After reading this story I'd suggest you to think twice before claiming something is impossible. On the other hand, I understand that it has to be done from time to time. Btw. still I have one more topic about imposibility to cover - to be continued...
Follow
