ImpossibleThreading
From APIDesign
(→NetBeans Threading) |
(→NetBeans Threading) |
||
| Line 9: | Line 9: | ||
[[I]] did what experts do. I said: ''"It's [[impossible]]!"'' and explained my reasoning. Looking back and reminding myself of the [[impossible|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! | [[I]] did what experts do. I said: ''"It's [[impossible]]!"'' and explained my reasoning. Looking back and reminding myself of the [[impossible|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, | + | 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). |
| - | 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 | + | |
| + | 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, | 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 | 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. | kind of deadlock for once and ever. | ||
Revision as of 15:42, 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 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.
Follow
