On Tue, Mar 26, 2013 at 7:31 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
> Above ideas could be useful to improve concurrency testing and can also be
> helpful to generate test cases for some of the complicated bugs for which
> there is no direct test.
I wonder how much explicit sync points would help with testing though.
It seems like they suffer from the problem that you'll only put sync
points where you actually expect problems and not where you don't
expect them -- which is exactly where problems are likely to occur.
Wouldn't it be more useful to implicitly create sync points whenever
synchronization events like spinlocks being taken occur?
And likewise explicitly listing the timing sequences to test seems
unconvincing. If we could arrange for two threads to execute every
possible interleaving of code by exhaustively trying every combination
that would be far more convincing. Most bugs are likely to hang out in
combinations we don't see in practice -- for instance having a tuple
deleted and a new one inserted in the same slot in the time a
different transaction was context switched out.
--
greg
