Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : Gianni Mariani
Date : Thu Feb 03 2005 07:13 am

David Schwartz wrote:
> "Gianni Mariani" <gi2nospam@mariani.ws> wrote in message 
> news:B6GdnRWW98G7A5zfRVn-2w@speakeasy.net...
> 
> 
>>I'm not sure how the GCC compiler implemented this, but I did show some 
>>code that requires a mutex check only on the first time throught the code, 
>>otherwise there is no check at all.  C++ already checks for prior 
>>construction on every pass through the code, this check can be used to 
>>also eliminate the need to lock a mutex.  The net effect is virtually 0 
>>overhead.
> 
> 
>     Your code is not portable. 

THREAD API's ARE NOT PORTABLE.... So far I've learned 4 of them,  what's 
your point ?

It relies on slippery and complex semantics
> that may or may not be available on future processors. 

You mean future processors that may never exist ?

There has been a
> major effort not to heap features onto C or C++ that require specific 
> intricate platform details to be supportable. C and C++ are supposed to run 
> on elevator controllers, remember?

Don't use threads in elevator contollers and you'll be better off !

> 
>     The big problem is that you have no way of knowing what optimizations 
> might be possible (and vital) in the future and what will be able to do 
> those optimizations. It may not be just the compiler and the processor, it 
> may be the memory hardware. To design a language feature around things that 
> just happen to work on particular platforms today is just terribly bad 
> practice, and had it been followed in the early days, C would be a dead 
> language today.

We have enough problems to solve today without having to invent 
non-existant ones.  This is spouting FUD, not computer science, when 
your future processor shows up, we'll fix it then.  Right now, if we can 
solve many issues with using threads in a generic and useful way, then 
we should do so.

> 
>     If you want to make C and C++ support threads, then support threading 
> primitives and don't add language features that can't be implemented with 
> the primitives you support.

The GCC bug fix an the fancy macro that I spouted earlier are not 
"primitives" of the C++ standard.  You can turn the GCC feature off and 
you don't have to use the ugly macro.

  And for the love of god, don't rely upon code
> that nobody can understand.

What are you talking about ?

.