POTD
-
Phrase of the day. "Race Condition" I'm newbie in multi-threading, so googling articles on it, and found an article which says ".....and this is a race condition".....i think i will never get over it....
Shukra wrote:
"Race Condition"
When you mistake exlax for chocolate.
I wouldn't have to be such a smartass if you weren't such a dumbass. http://www.hq4thmarinescomm.com[^] My Site
-
Phrase of the day. "Race Condition" I'm newbie in multi-threading, so googling articles on it, and found an article which says ".....and this is a race condition".....i think i will never get over it....
Today's News articles had a good free e-book on threading. http://blogs.msdn.com/b/nikosan/archive/2010/10/12/7-freely-available-e-books-guides-i-found-essential-for-net-programmers-and-architects.aspx[^]
-
Shukra wrote:
"Race Condition"
When you mistake exlax for chocolate.
I wouldn't have to be such a smartass if you weren't such a dumbass. http://www.hq4thmarinescomm.com[^] My Site
-
Today's News articles had a good free e-book on threading. http://blogs.msdn.com/b/nikosan/archive/2010/10/12/7-freely-available-e-books-guides-i-found-essential-for-net-programmers-and-architects.aspx[^]
-
Phrase of the day. "Race Condition" I'm newbie in multi-threading, so googling articles on it, and found an article which says ".....and this is a race condition".....i think i will never get over it....
"Race condition" is a term that comes from early digital design. I was there, so take my word for it... The principles apply just as well for software design, however. In combinatorial logic circuit design it was common to assume that all devices change state at the same moment. That's the textbook case, taught in school. In the real world, this isn't the case. Real digital devices take a few nanoseconds to change state and settle down. When circuits are designed that depend on simultaneous state changes, race conditions can occur. In this scenario, the changes in state are assumed to be completed before another part of the circuit reads the result and acts upon it. If not all of the expected inputs have settled to a final state before the next circuit samples the result, unexpected results can occur. The use of flip-flops driven by a common clock solves this problem, but at a cost in component prices and reliability - adding more circuit components always reduces MTBF. In software, especially code that uses threads, it's critical to never assume that an independent process will be complete when another thread is ready to accept the result. The state of all independent processes should be sampled and verified before any dependent process attempts to continue execution. It's not hard to do, but it does take a bit of discipline to get into the habit of validating intermediate results before proceeding with execution.
Will Rogers never met me.
-
"Race condition" is a term that comes from early digital design. I was there, so take my word for it... The principles apply just as well for software design, however. In combinatorial logic circuit design it was common to assume that all devices change state at the same moment. That's the textbook case, taught in school. In the real world, this isn't the case. Real digital devices take a few nanoseconds to change state and settle down. When circuits are designed that depend on simultaneous state changes, race conditions can occur. In this scenario, the changes in state are assumed to be completed before another part of the circuit reads the result and acts upon it. If not all of the expected inputs have settled to a final state before the next circuit samples the result, unexpected results can occur. The use of flip-flops driven by a common clock solves this problem, but at a cost in component prices and reliability - adding more circuit components always reduces MTBF. In software, especially code that uses threads, it's critical to never assume that an independent process will be complete when another thread is ready to accept the result. The state of all independent processes should be sampled and verified before any dependent process attempts to continue execution. It's not hard to do, but it does take a bit of discipline to get into the habit of validating intermediate results before proceeding with execution.
Will Rogers never met me.
All Hail Woger!
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H
