Subj : Re: double-checked locking in C
To   : comp.programming.threads
From : Joe Seigh
Date : Fri Jul 08 2005 10:42 am

David Schwartz wrote:
> "Joe Seigh" <jseigh_01@xemaps.com> wrote in message 
> news:DPWdnS07t_9x7lPfRVn-vA@comcast.com...
> 
> 
>>Posix guarantees aren't formally defined.  The test suites no more prove
>>the implementation is "correct" any more than testing a multi-threaded 
>>program
>>proves it is "correct".
> 
> 
>     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.  
> 
> 
>>And yes, your code is future proof if you don't actually use anything new 
>>and
>>your compiler and runtime still exist.   And your posix pthreads programs 
>>will
>>still work as long as you don't try to use anything not anticipated by 
>>pthreads
>>at the time you wrote the program, and posix pthreads has been ported.
> 
> 
>     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".
> 
> 
>>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.

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



-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.