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


"Joe Seigh" <jseigh_01@xemaps.com> wrote in message 
news:b-udnUEoQ6uDH1PfRVn-rg@comcast.com...

>>     You are seriously arguing that the test suites give you no idea 
>> whether programs similar to the test suites will work?

> They don't prove they will work.   It's the general problem of proving a
> program is "correct" made more difficult by a lack of formal definitions.
> I.e. what does "correct" even mean.

    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?

    At first that is exactly what you said. Now you're retreating to the 
position that test suites don't guarantee a particular program will work. 
Nobody ever said they did.

    I'm saying a situation where you have a test suite, and your program 
looks like the programs in the test suite, is much better than a situation 
where you don't, or where your program looks nothing like the ones in the 
test suite.

>>     Your compiler and runtime don't have to exist. You just have to have 
>> not done anything bizarre that isn't anticipated by the standards and the 
>> people who supply the implementations of them. I'm advocating not doing 
>> anything bizarre and you are saying it doesn't matter.

> The definition of "bizarre" being?  Apart from "we didn't anticipate it so
> that means it's bizarre".

    When you write a program, you have some target in mind. Maybe it's every 
WIN32 system. Maybe it's every system that claims to support C99. Whatever. 
The expectation is that the code will work on every platform that meets the 
target you had in mind when you wrote the code. If you stick to requiring 
only the guarantees the target platforms provide, and there's a test suite 
for those guarantees, your odds of having the code not work are sharply 
reduced.

>>>But DCL is just as portable as pthreads in that somebody has to know what 
>>>both
>>>are supposed to do in order to do the port.

>>     But we aren't talking about porting DCL versus porting pthreads. The 
>> choice is not "should I use DCL or should I use pthreads". The choice is 
>> "should I comply with the standards such that later implementations of 
>> the standard will still work with my code so long as they comply with the 
>> standards or should I use code that happens to work and doesn't conform 
>> to the standards and have to deal with any future problems myself".

> That's what the C/C++ people keep saying, if you stick to the C standard
> and not use anything not defined by the standard (e.g. threads) your
> programs will continue to work in the future.

    They are correct. And if the C standard alone provides everything you 
need to get a job done, you would probably do very, very well from a 
portability standard if you stick to only what's in the C standard. If the C 
standard alone doesn't provide enough, or there are unacceptable tradeoffs 
with just using C (for example, if you need a GUI or could really benefit 
from threads), then you have to take a step up. Portability will go down 
when you do that.

    The point is to realize that doing something outside a standard 
decreases your portability and increases your pain. You should make damn 
sure there are benefits that matter before you take the pain.

>>>Really, this is getting almost as tiresome as the "C has nothing to do 
>>>with threads"
>>>refrain in the C/C++ newsgroups when confronted by anything outside of 
>>>their closed
>>>universe.  If you want to ignore stuff that's strictly not Posix 
>>>pthreads, fine.
>>>Ignore it.   But this is not comp.programming.pthreads and posix heresy 
>>>is not a mortal
>>>sin here.

>>     This has nothing special to do with POSIX pthreads. The argument 
>> would be precisely the same if we were talking about WIN32 threads. On 
>> WIN32, there are things that are guaranteed and things that happen to 
>> work. If you use the things that are guaranteed, you can be reasonably 
>> assured that your code will continue to work on future WIN32 platforms. 
>> If you use things that happen to work, you had better be prepared to 
>> maintain you code or see it break on future hardware.

> You're assuming that there will be no other api's with support out there 
> besides
> pthreads or win32.

    Huh? I assume there will be later APIs. I just don't believe that WIN32 
or POSIX will die off. To put it another way, if you want to write code 
today that's going to work in the future, you will do best if you stick to 
some standard that you expect to still be supported in the future. POSIX is 
not going away. WIN32 is not going away.

>  It's your choice whether you want to stick with just those
> or not.  But at the rate Posix pthreads is keeping up with the state of 
> the art,
> it's current somewhere in the early 90's AFAICT, you're going to miss out 
> on a
> lot of new technology.

    You will miss out on new technology if you stick to a slowly-evolving 
standard, that is true. If you need that new technology, then that may weigh 
in your decision. It would be prudent to do a few things when you need to do 
that, if you are mostly sticking to a standard:

    1) If possible, also implement the code in a standard conformant way 
(fallback code), and have compiler switches to choose which code to use.

    2) Put more effort into commenting such code, since it's more likely it 
will have to be rewritten later.

    3) Ensure that there really is a benefit that's worth the possible 
future pain.

    DS

.

0