On 5/13/2014 11:24 AM, Dimitry Sibiryakov wrote: > 13.05.2014 17:10, Jim Starkey wrote: >> On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote: >>>> If I'm not mistaken, these repeating index entries works as a >>>> reference counters and >>>> allow to stop using staying list for indexes even in current code for the >>>> same reason as >>>> for blobs: three versions are enough for decision making. >>>> >> No, it only makes race conditions more elusive... > Can you provide a draft scenario when it can lead to a problem? > Fortunately, we have a right guy for testing such things... :) >
Nope, can't prove the code doesn't catch all possible race conditions between two complex independent pieces of code. Nor can I prove that somebody in the future won't make an innocent change that fails once every couple of million times. What I've learned over many years is that race conditions are subtle and often lethal and are best architected away rather than coded around. Writing a lot of non-interlocked code using atomic instructions on SMP tends to give one a deep respect for the maliciousness of the computer gods. A one instruction window is really hard to find in testing... I'll concede that A-B-A index updates don't happen enough to loose a lot of sleep over, but it strikes me as inelegant to have two consecutive identical index entries. Much too fragile for my taste. For example, when cleaning up after a crash, does the code scan all record versions to avoiding taking out a single version when the code was expecting a double entry? ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
