85b Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads,comp.std.c From : David Schwartz Date : Thu Feb 17 2005 08:19 pm "David Hopwood" wrote in message news:M9aRd.129957$K7.23610@fe2.news.blueyonder.co.uk... > David Schwartz wrote: >> "Alexander Terekhov" wrote in message >> news:42131205.B72DB5C2@web.de... >> >>>Under C/POSIX different objects just can't have the same address. >>>And threads share the entire address space. By definition. >> >> That's ridiculous. Providing no strictly-conforming code can tell the >> difference, POSIX is silent. > I keep hearing this idea that POSIX (or Standard C) only imposes > requirements for strictly-conforming code. Where does it come from? > Can you explain why you believe it? Common sense. Any alternative would mean that there could only be strictly-conforming code. Please, give me an example of how a standard could impose requirements upon things it doesn't define. > C99 4 #3 definitely (although not particularly clearly) says otherwise. > ("A program that is correct in all other aspects, operating on correct > data, containing unspecified behavior shall be a correct program and act > in accordance with 5.1.2.3.") Sure, if it's "correct in all other aspects". This simply provides a definition of what it means for a program to be "correct in all other aspects". > This is quite relevant to c.p.threads, BTW. Not imposing any requirements > for code that has nondeterministic, i.e. unspecified, behaviour would make > POSIX useless for multithreaded programming. If you mean it would make C or C++ useless for multithreaded programming, IT IS. What you need is another standard, such as the POSIX pthreads standard, which must specifically say how the C/C++ standard is going to apply to multithreaded code. The C/C++ standards alone say nothing about multithreaded code. Is code that is multithreaded "correct in all other aspects"? That's what another standard would have to say. DS . 0