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

David Schwartz wrote:
> "Joe Seigh" <jseigh_01@xemaps.com> wrote in message 
> news:I5OdnbMTivIl9lPfRVn-1g@comcast.com...
> 
> 
>>So given that both can break and
>>somebody has to do the porting, I'd say both DCL and Posix are equally
>>portable except there's probably more headcount available to do the 
>>porting
>>for Posix pthreads.
> 
> 
>>AKA future proofing and no, you can't future proof anything.  That's why
>>C doesn't work for things it never anticipated and Posix pthreads won't
>>work for things it never anticipated.
> 
> 
>     C code I wrote in the 1980s for Apple ]['s compiles and runs on my dual 
> P3 Linux box with no problem. I'll bet computers in 20 years (with hardware 
> capabilities I can't even imagine now) will provide the ability to compile 
> POSIX-compliant code with no changes.
> 
>     It is possible that, for example, supporting POSIX-style mutexes may 
> reduce performance some horrible amount compared to some new style of 
> synchronization that works better on the hardware in 20 years. But it will 
> still be possible to implement mutexes and people will do it. (The machine 
> will have no problem emulating one of today's CPUs if it has to.)
> 
>     As far as DCL versus pthreads and future proofing, the difference is 
> that if you implement some code that happens to work on your machine when 
> you tested it, you will have to *find* that code, remember what is was 
> supposed to do 20 years later, and figure out *why* it doesn't work anymore 
> and then reimplement it and its side effects. This assumes that you even 
> know that it broke and don't find out when it crashes or gives wrong results 
> at the worst possible time.
> 
>     On the flip side, pthreads is a documented standard that will be 
> provided by your vendor or system supplier. Test suites exist to make sure 
> the implementation really does provide the guarantees it's supposed to.

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

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.

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.

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.


-- 
Joe Seigh

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

.