Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : David Schwartz Date : Thu Feb 03 2005 06:31 pm "Gianni Mariani" wrote in message news:ZZGdnciZzPwTop_fRVn-gg@speakeasy.net... > David Schwartz wrote: >> "Gianni Mariani" wrote in message >> news:B6GdnRWW98G7A5zfRVn-2w@speakeasy.net... >> Your code is not portable. > THREAD API's ARE NOT PORTABLE.... So far I've learned 4 of them, what's > your point ? My point is that you can't defend a language feature against accusations about implementation problems by showing a non-portable implementation. > 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 ? Yes, I do. Before adding a feature to a *language* it is important that it be implementable in a generic way. Not a way that relies on quirks of particular processors. Features that rely on such quirks belong in platform-specific places, not portable places. >> 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 ! Why not? >> 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. The key is a "generic" way. If you can implement the feature with generic primitives, then fine. If you can't, then not fine. > And for the love of god, don't rely upon code >> that nobody can understand. > What are you talking about ? I'm talking about complex variations on DCL that nobody knows whether they are correct or not. I'm talking about code that has subtle flaws and design problems that don't belong in the core of a language. DS .