Subj : Re: Boost.Threads on its way to C++0x To : comp.programming.threads From : Uenal Mutlu Date : Sun May 01 2005 04:47 am "David Hopwood" wrote > Uenal Mutlu wrote: > > "David Hopwood" wrote > >>gottlobfrege@gmail.com wrote: > >>>Ben Hutchings wrote: > >>>>Peter Dimov wrote: > >>>> > >>>>>How do you solve the race condition WRT the hidden > >>>>>compiler-generated boolean flag? > >>>> > >>>>You fix it in at the language level. [...] > >>> > >>>Yes, it should definitely be optional - you don't want the overhead for > >>>all the cases where you know it is not needed. One of C++'s mantras I > >>>believe... > >> > >>And as wrong-headed in this case as it is in many other cases. The > >>compiler can tell which statics are guaranteed to only be accessed > >>by a single thread (the graph of which functions potentially call > >>each other that is needed to determine this, is also needed for other > >>optimizations). > > > > True, but this can only work if threads are part of the core language. > > Yes, as they obviously should be anyway. > > The academic concurrent programming community has for 30 years been > telling anyone who will listen that concurrency must be supported at the > language level, but this view seems to be gaining a bit more traction > recently, e.g. . I agree threads should be part of the core language. Your statement above ("The compiler can tell which statics are guaranteed to only be accessed by a single thread") is a very important statement. I would say that it even can be generalized by replacing the "static" by "variable" (for example a class data member used by multiple threads). Indeed the compiler could detect which variables are accessed (or code blocks called) from multiple threads and could protect these automatically by making the access atomic or operating in a critical section, all done at compile time (and a compiler option would list which variables/code regions are affected). This would make multithread programming much easier and safer. But IMO it would not totally eliminate the need for user level locking for a logical set of operations (ie. "transaction" like ops). Nevertheless, this issue (threads) should get high priority to become part of the language standard, and the compilers should offer such options and optimizations for MT code. In the mean time a hack/hint like #pragma threadproc #pragma threadproc_end or a similar thing could be used to tell the compiler that the code inbetween is called from multiple threads, so the compiler writers can implement what was said above also for code which uses external threading libraries. I think all this is easy to implement; one just needs to know the threadproc's and the code therein... .