ImpossibleThreading

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(NetBeans Threading)
Line 11: Line 11:
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 worked OK (when the code was new), but then it turned out this style is actually a source of major hard to solve deadlocks and long pauses when rendering the UI (a typical syndrome of designing a solution for something that is [[impossible]] to be solved).
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 worked OK (when the code was new), but then it turned out this style is actually a source of major hard to solve deadlocks and long pauses when rendering the UI (a typical syndrome of designing a solution for something that is [[impossible]] to be solved).
-
Again I acted as [[impossible|experts do]], I seeked for a way to eliminate [[deadlock]]s - but not due to a master plan, but through a hard work. I learned how to simulate any
+
Again I acted as [[impossible|experts do]], I tried to find out why the offered solution is completely stupid. Maybe I was just to proud, but maybe I just didn't want to rewrite most of the [[NetBeans]] [[API]]s (and change them incompatibly) to a new threading scheme without guaranteed result.
-
deadlock in a unit test (see [[FlowControllingTest]] for details) and only then fix it. As a result the number of deadlocks started to decrease. Previously we fixed something,
+
 
-
without even having a reproducible case and then the deadlock could reappear. With a test, we could be sure we prevent such
+
As such I seeked for ways to eliminate our [[deadlock]]s - but not thanks to a new and unproven master plan, but with as little changes as possible (e.g. trying to not share 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 [[deadlock]]s 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).
-
kind of [[deadlock]] for once and ever.
+
 
 +
The [[impossible|expert]] (e.g. me) was again right. However, given the few years of struggling I had to go through, I'd react differently to the initial question of my manager: rather than saying fighting [[deadlock]]s is [[impossible]], I'd say we need to create a process to help our developers to fight with [[deadlock]]s (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]]. Still I have one more topic to cover - [[TBD|to be continued]...

Revision as of 20:55, 2 January 2015

Another story about problems with explaining that something is impossible is here. This time it touches on my experience with threading.

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 will 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.

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 worked OK (when the code was new), but then it turned out this style is actually a source of major hard to solve deadlocks and long pauses when rendering the UI (a typical syndrome of designing a solution for something that is impossible to be solved).

Again I acted as experts do, I tried to find out why the offered solution is completely stupid. Maybe I was just to proud, but 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.

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 share 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).

The expert (e.g. me) was again right. However, given the few years of struggling I had to go through, I'd react 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. Still I have one more topic to cover - [[TBD|to be continued]...

Personal tools
buy