Re: [boost] Re: Re: Thread-Local Storage (TLS) and templates

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2003-02-21 09:48:57

David Abrahams <dave_at_[hidden]> writes:

| Gabriel Dos Reis <gdr_at_[hidden]> writes:
| 
| > David Abrahams <dave_at_[hidden]> writes:
| >
| > | Gabriel Dos Reis <gdr_at_[hidden]> writes:
| > | 
| > | > However, my point is that
| > | >
| > | >   * a class is closed: that is, by the time you put the closing brace,
| > | >     the "offset" of the data member is a compile-time constant.
| > | >
| > | >   * the number of thread local variables is potentially unbounded,
| > | >     meaning that, using your analogy, the offset of the corresponding
| > | >     data-member is not known by the time the compiler finishes
| > | >     processing a given translation unit.
| > | 
| > | OK... is that a problem?
| >
| > As I'm understanding the issue, yes.  I would love to be proved wrong.
| >
| > |  The address of a static global is not known
| > | when the compiler finishes processing a given translation unit either.
| >
| > Sure the logical address is known.
| >
| > As opposed to the address of a variable with a TLS.
| 
| It has just one "logical address", which will turn out to correspond
| to different physical addresses depending on the thread executing at
| the time.  When the implementation handles it at compile-time, it uses
| only the logical address.  At the compile-time/runtime boundary the
| logical address is converted to a physical address by dereferencing
| off the base TLS pointer.  This is just like a data member pointer.  I
| still don't see a problem.

The problem has to do with the "dependency on the address depending on
the thread executing at the time".

Either you're assuming you've an unspoken extended definition of
the C++ types as currently defined or the analogy you're attempting
with address of data members ought to be better technically supported.

-- Gaby