JaroslavTulach at 21:33, 2 January 2015 - 2015-01-02 21:33:33

←Older revision Revision as of 21:33, 2 January 2015
Line 31: Line 31:
''"OK, now I see the other company can't create the [[wikipedia:Finite-state machine|finite-state automaton]] properly. Can you please build it for us?"''
''"OK, now I see the other company can't create the [[wikipedia:Finite-state machine|finite-state automaton]] properly. Can you please build it for us?"''
-
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
+
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time? Somebody might give up, but as the [[ImpossibleThreading|next story shows]] some won't!
-
 
+
-
The story continues by description of [[ImpossibleThreading]] issues...
+
-
 
+
[[Category:Video]]
[[Category:Video]]

JaroslavTulach at 21:32, 2 January 2015 - 2015-01-02 21:32:13

←Older revision Revision as of 21:32, 2 January 2015
Line 33: Line 33:
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
-
[[ImpossibleThreading|To be continued]]...
+
The story continues by description of [[ImpossibleThreading]] issues...
[[Category:Video]]
[[Category:Video]]

JaroslavTulach: /* Finite-state Machine */ - 2015-01-02 15:36:26

Finite-state Machine

←Older revision Revision as of 15:36, 2 January 2015
Line 33: Line 33:
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
-
<!--
+
[[ImpossibleThreading|To be continued]]...
-
== [[NetBeans]] Threading ==
+
-
 
+
-
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 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.
+
-
-->
+
-
[[TBD|To be continued...]]
+
[[Category:Video]]
[[Category:Video]]

JaroslavTulach at 14:14, 20 October 2014 - 2014-10-20 14:14:32

←Older revision Revision as of 14:14, 20 October 2014
Line 33: Line 33:
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
 +
<!--
== [[NetBeans]] Threading ==
== [[NetBeans]] Threading ==
Line 46: Line 47:
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.
 +
-->
 +
[[TBD|To be continued...]]
 +
-
[[TBD]]
 
[[Category:Video]]
[[Category:Video]]

JaroslavTulach: /* NetBeans Threading */ - 2014-10-19 20:04:45

NetBeans Threading

←Older revision Revision as of 20:04, 19 October 2014
Line 41: Line 41:
[[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!
[[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.
+
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.
[[TBD]]
[[TBD]]
[[Category:Video]]
[[Category:Video]]

JaroslavTulach: /* NetBeans Threading */ - 2014-10-19 19:00:13

NetBeans Threading

←Older revision Revision as of 19:00, 19 October 2014
Line 40: Line 40:
[[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!
[[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.
[[TBD]]
[[TBD]]
[[Category:Video]]
[[Category:Video]]

JaroslavTulach: /* NetBeans Threading */ - 2014-10-19 18:47:46

NetBeans Threading

←Older revision Revision as of 18:47, 19 October 2014
Line 39: Line 39:
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.
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. 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 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!
[[TBD]]
[[TBD]]
[[Category:Video]]
[[Category:Video]]

JaroslavTulach: /* NetBeans Threading */ - 2014-10-19 08:02:28

NetBeans Threading

←Older revision Revision as of 08:02, 19 October 2014
Line 35: Line 35:
== [[NetBeans]] Threading ==
== [[NetBeans]] Threading ==
 +
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 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. No surprise my boss didn't listen. I lost my credibility as an expert and he selected somebody else to make [[NetBeans]] [[deadlock]] free!
[[TBD]]
[[TBD]]
[[Category:Video]]
[[Category:Video]]

JaroslavTulach: /* Finite-state Machine */ - 2014-10-19 07:39:59

Finite-state Machine

←Older revision Revision as of 07:39, 19 October 2014
Line 21: Line 21:
Your new automaton should then accept word like "01" or "000000000111111111" and reject words like "10" or "00010" or "001". What should you say to such customer?
Your new automaton should then accept word like "01" or "000000000111111111" and reject words like "10" or "00010" or "001". What should you say to such customer?
-
The right answer is to say: ''"It's [[impossible]]!"'' Enough to read description of [[wikipedia:pushdown_automaton|pushdown automaton]] to understand why, but of course, your customer is [[clueless]] and won't bother. Even if you try to explain what the problem is, you are only going to be seen as incapable. Your great reputation is being lost. Morever there is another company specialized in construction of [[wikipedia:Finite-state machine|Finite-state automaton]]s and when your customer visits them, they (as good business men) say: ''"Of course, we'll build the automaton!"''
+
The right answer is to say: ''"It's [[impossible]]!"'' Enough to read description of [[wikipedia:pushdown_automaton|pushdown automaton]] to understand why, but of course, your customer is [[clueless]] and won't bother. Even if you try to explain what the problem is, you are only going to be seen as incapable. Moreover there is another company specialized in construction of [[wikipedia:Finite-state machine|Finite-state automaton]]s and when your customer visits them, they (as good business men) say: ''"Of course, we'll build the automaton!"''
 +
Customer gets his machine and is happy. Competing company is happy too. Only your expert reputation is being damaged. But you know the automaton cannot work! So you visit the customer and ask for permission to use his automaton for a while and yes, after a little bit of time you find a word that is accepted, even it should not be. It is not a simple word, it has tens of zeros at beginning and even more ones at the end. But you'd done it! Satisfied you run to the customer to tell him, it is all a fake.
 +
Customer is a bit worried and contacts the supplier of the machine, who sticks to the business note and admits there is a bug in his automaton which he is going to fix. In a few weeks a new automaton, ten times bigger than the old one, is being deployed to the customer and it fixes the so called bug: the incorrectly accepted word is not being rejected. Happiness all over. Except in your camp: you know it is just another bigger fake. It is [[impossible]] to create such finite automaton!
 +
Hurrying to save your reputation, you ask the customer again for a permission to inspect the automaton. You study it for weeks and after that you finally find another incorrectly accepted word: this time is starts with thousands of zeros followed by even more ones. Exhausted, but happy you visit the customer. He finally listens to you and is ready to accept that the competing company is a gang of ignorants. But he still may not get it:
 +
 +
''"OK, now I see the other company can't create the [[wikipedia:Finite-state machine|finite-state automaton]] properly. Can you please build it for us?"''
 +
 +
Your expert credit is back. But the fact that something is [[impossible]] is somehow not getting through. What will be your answer this time?
 +
 +
== [[NetBeans]] Threading ==

JaroslavTulach: /* Finite-state Machine */ - 2014-10-19 07:18:34

Finite-state Machine

←Older revision Revision as of 07:18, 19 October 2014
Line 21: Line 21:
Your new automaton should then accept word like "01" or "000000000111111111" and reject words like "10" or "00010" or "001". What should you say to such customer?
Your new automaton should then accept word like "01" or "000000000111111111" and reject words like "10" or "00010" or "001". What should you say to such customer?
-
The right answer is to say: "It's [[impossible]]!" It is enough to read description of [[wikipedia:pushdown_automaton]], but of course, your customer is [[clueless]] and won't bother. Even if you try to explain what the problem is, the customer will only believe that you are incapable. Your great reputation is being lost. Morever there is another company specialized in construction of [[wikipedia:Finite-state machine|Finite-state automaton]]s and when your customer visits them, they (as good business men) say: "Of course, we'll build the automaton!"
+
The right answer is to say: ''"It's [[impossible]]!"'' Enough to read description of [[wikipedia:pushdown_automaton|pushdown automaton]] to understand why, but of course, your customer is [[clueless]] and won't bother. Even if you try to explain what the problem is, you are only going to be seen as incapable. Your great reputation is being lost. Morever there is another company specialized in construction of [[wikipedia:Finite-state machine|Finite-state automaton]]s and when your customer visits them, they (as good business men) say: ''"Of course, we'll build the automaton!"''
 +
 
 +