[cpp-threads] N2880 and thread_local variables

[Peter Dimov]

Anthony Williams:
> Here is Peter's example:
> > As a counterpoint, however, consider this task:
> >
> > void task()
> > {
> >    delete new int;
> > }
> >
> > and assume that the implementation of operator new uses thread_local
> > variables to maintain a per-thread free list.
>
> Hmm. I see the problem here. Obviously, the runtime could optimize 
> operator new so this wasn't a problem, whatever the actual behaviour of 
> thread_local and thread_local_context.
>
> However, there are a class of uses of thread-local objects where 
> expensive-to-construct objects are cached in thread-local storage for the 
> life of a thread, and similar concerns could be said to apply to them.

The primary motivation of using thread locals in the use cases I have in 
mind is to avoid synchronization. It is not the construction and destruction 
that is expensive, it is the contention.

> That said, I think it is *precisely* these expensive-to-construct and 
> therefore probably heavy-resource-using objects, probably also with 
> non-trivial destructors, that N2880 is concerned about.

No matter what N2880 says, rendering thread_locals ineffective in achieving 
high performance in the presence of concurrency would be a mistake.