ImpossibleThreading

From APIDesign

Revision as of 15:39, 2 January 2015 by JaroslavTulach (Talk | contribs)
Jump to: navigation, search

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 remembers 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. Again I acted as experts do, I seeked for a way to eliminate deadlocks - but not due to a master plan, but through a hard work. I learned how to simulate any deadlock in a unit test 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 kind of deadlock for once and ever.

Personal tools
buy