Re: double-checked locking in C


"Joe Seigh" <jseigh_01@xxxxxxxxxx> wrote in message
news:b-udnUEoQ6uDH1PfRVn-rg@xxxxxxxxxxxxxx

>> 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


.

Relevant Pages

  • Re: Need suggestions for C links.
    ... You mean "it's a lot easier to prove a flawed implementation incorrect ... A standardised full test suite for C along the lines of Ada's could go ... syntax parsing, type conversions, diagnostics, operator and standard ... than to find people willing to develop a compiler. ...
    (comp.lang.c)
  • Re: Fortran 2003 Test Suite
    ... for a test suite just for the syntax rules and constraints. ... Then of course the original F95 standard had four different ... specification or initialization expressions? ...
    (comp.lang.fortran)
  • Re: Need suggestions for C links.
    ... When you write that there's a lot more to "it" than a test suite, ... it was VERY expensive but the US government paid for it. ... The tests themselves would be in standard C. ... So all the compilers will fail. ...
    (comp.lang.c)
  • Re: Need suggestions for C links.
    ... When you write that there's a lot more to "it" than a test suite, ... conformance to the language standard. ... Since the standard allows extensions, ... I wasn't suggesting that the framework needs to be ...
    (comp.lang.c)
  • POSIX 1003.1 Frequently Asked Questions
    ... This is the Frequently Asked Questions file for the POSIX 1003.1 ... Where can I download the 1003.1 standard from? ... Although originated to refer to the original IEEE Std 1003.1-1988, ... What about POSIX Certification?* ...
    (comp.unix.programmer)