Subj : Re: [RFC] Boost.Threads on its way to C++0x To : comp.programming.threads From : Joe Seigh Date : Thu Apr 28 2005 10:35 pm On Fri, 29 Apr 2005 01:13:16 +0100, Ben Hutchings wrote: > Joe Seigh wrote: > >> It doesn't look like any changes at the language level, so the whole >> range of threading issues like word tearing, false sharing, etc... >> isn't being addressed. Plus the issues that will show up with lock-free >> programming like atomicity, memory visibility, compiler optimization >> directives, storage attributes, etc... > > > That's a separate proposal. See > , > , > and archived discussions: > . > Well, that explains why it's been relatively quiet here lately. I think it would be a mistake to define everything as part of the language and not support implementing synchronization via libaries. C++ would become a dead language as far as advances in multi-threading techniques is concerned. There's a reason new synchronization techniques are being done in C/C++ and not Java, ADA, or one of the other dead languages. C/C++ doesn't make it impossible to do things** that haven't been preconceived of by a small cabal of language designers. It would be rather ironic if C++ suddenly made it impossible to implement an efficient thread-safe lock-free smart pointer that everyone seems to want. As far a defining the memory model, I've done formal semantics for synchronization primatives without having to resort to definition by implementation or meta-implementation (like the Java memory model) so I have a pretty good appreciation for the issues here. I think one of the reasons C++ types are having a hard time is they're used to pre-condition/post-condition stuff which doesn't work too well in a multi-threaded environment. ** case in point. In Java 1.0 you could do multiple condition variables using a slight hack. They removed the ability to do the hack for no discernable reason other than maybe the hack offended somebody's sensibilities. They added the capability for multiple condition variables back in but it doesn't work with normal monitor locks, only a new lock type that can't be used in the normal synchronized statement. What's really strange is the fix they orginally put in is that monitor unlocks had to match and be in the same frame that did the monitor lock, yet AFAICT the new locks are just library implementations and have no such restriction. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. .