6cf
Subj : Re: Boost.Threads on its way to C++0x
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sat Apr 30 2005 02:22 pm

"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.  Hans Boehm reported that
> >>"[t]here appeared to be consensus among those attending the last C++
> >>standards meeting that both [synchronised and unsychronised] options
> >>should be provided to the programmer"
> >><http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/mm.html>.
> >
> > 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.
That is: the compiler must know what a thread is.

> So it can remove any overhead when it is safe to do
> so -- and it won't make mistakes in determining when this is safe,
> unlike programmers. The remaining overhead is low, and accesses to
> initialized statics occur rarely enough in typical programs that it
> won't have a noticable effect on overall performance anyway.
>
> If manual annotations are used for this, it will just be an excuse
> for compiler implementors not to optimize it properly.

.

0