Subj : Re: double-checked locking in C
To   : comp.programming.threads
From : David Schwartz
Date : Fri Jul 08 2005 07:31 pm


"Joe Seigh" <jseigh_01@xemaps.com> wrote in message 
news:H66dnUWQYrM5l1LfRVn-gg@comcast.com...

>>     We are talking about one case where you have a test suite compared to 
>> a case where you don't. You are seriously arguing that an implementation 
>> test suite is no help at all in making sure an implementation correctly 
>> supports a standard? Is that really your position?

> I'm not sure where you're going here.  What do you mean by similar?
> Exactly the same?  How much of a difference is allowed  before different
> results are allowed?

    By similar I mean that you don't do anything that requires some 
guarantee that isn't tested by the test suite. For example, the test suite 
will likely test that variable modified by one thread holding a particular 
lock is seen correctly by another thread that tests it under that same lock. 
It probably won't test with different locks. So the probability of your code 
continuing to work is greater if it too uses the same locks.

> That raises an iteresting issue.  If I come up with a new form of 
> synchronization
> but don't provide any formal definition (which is a valid point of 
> contention)
> can I come up with a set of testcases and say that if they run it proves 
> the
> implementation is correct?  For programs which are similar to the 
> testcases that is.
> Just curious.  There's other people besides me that would be interested in 
> the
> answer here.

    This question is mostly just about what it means for something to be 
"correct". If you call something a "mutex" and provide no definition, people 
will still rationally expect it to provide mutual exclusion. You could 
define "correct" as "passing the test cases"; however, if the test cases are 
developed at the same time as the new form of synchronization, an 
implementation that simply tested for the test cases and recited the correct 
answer by rote would be "correct".

    I would argue that the test cases and the implementation must both be 
aiming at some particular effect. That effect may or may not be well 
documented (obviously, it's better if it is), but the implementation and the 
test cases are both correct if they provide, and test for, that desired 
effect.

    DS

.