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

[David Abrahams]

Alexander Terekhov <[EMAIL PROTECTED]> writes:

> I have yet to see a compelling reason to embrace the MS
> ``TLS-template'' innovation.

Ah.  Well, that's an entirely different matter ;-).  I was going on
the assumption that there was a reasonable argument for the existence
of the feature, and just arguing that it is possible.  I have no
position on whether it's desirable.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Gabriel Dos Reis]

"Ken Hagan" <[EMAIL PROTECTED]> writes:

| Alexander Terekhov wrote:
| >
| > Uhmm. In return, I venture to suggest that MS-TLS can and shall be
| > characterized as ``utterly busted.''
| 
| Fine, but the OP asked about existing practice and the bugs
| don't change the fact that "&k" can be a template parameter
| if the compiler is willing to thunk its way around the TLS
| implementation under the hood.

I think extreme caution should be exercised with that line of reasoning.

There is what that particular implementation does with its extensions and
there are various mulit-threading models, what the standard language is
defined to be and ways to extend it to support multi-thread and thread
local storage.  In that regard, bugs in either the design or the
implementation don't count as arguments for not being cautious about
what that implementation does. 

That may sound obvious but I feel that need to be stated.

-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[William E. Kempf]

Edward Diener said:
> "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Ken Hagan wrote:
>> >
>> > Alexander Terekhov wrote:
>> > >
>> > > I, for one, believe strongly that "&k" is nothing but
>> > >
>> > > "static_cast(pthread_getspecific(__k_key));"
>> > >
>> > > It *isn't* a compile-time constant (just like &errno isn't a
>> compile time constant).
>> >
>> > MSVC has no pthread_getspecific(), so I venture to suggest that your
>> belief probably isn't valid for that compiler.
>>
>> Uhmm. In return, I venture to suggest that MS-TLS can and shall be
>> characterized as ``utterly busted.''
>>
>> "If a DLL declares any nonlocal data or object as __declspec(thread),
>>  it can cause a protection fault if dynamically loaded."
>
> This is well-known by many and has never been hidden by MS. It doesn't
> mean __declspec(thread) is busted, it just means that it is limited to
> only those cases in which the DLL is not dynamically loaded, which is
> the vast majority of cases. Of course to make TLS completely foolproof,
> one does not use __declspec(thread) but instead one uses the Win32 TLS
> API functions instead.

Where you run into issues with TLS cleanup ;).

I won't be as critical as Alexander, but I will agree that the MS TLS
implementation has serious design issues which need to be corrected.

-- 
William E. Kempf


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Gabriel Dos Reis]

"Ken Hagan" <[EMAIL PROTECTED]> writes:

| I could write...
| 
| int fk() { return k; }
| 
| and re-cast my template to expect a pointer to function and then
| write C<&fk>. This is perfectly legal under the current language
| rules, and gives a type whose behaviour depends on the thread that
| is using it.

This analgoy does not cut it: You don't have a function "fk" by thread.
You have a -single- function designator.  And the return value depends on
the calling thread.

-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Gabriel Dos Reis]

David Abrahams <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| 
| > | OK, whatever.  I guess I should've said that you can instantiate a
| > | template on &k with sensible results.  Whether or not you want to call
| > | it a constant is another semantic matter.  I'd call it a constant
| > | which evaluates differently in different threads.  
| > ^^
| >
| > And that isn't just a word-game as your message might imply it.
| 
| I never meant to imply that it's a word game, just that I'm only
| willing to concede "not a constant-ness" for some very narrow
| definition of the word "constant."  If you think of threads as being
| truly concurrent, the value actually _is_ constant (just different in
| different threads).

There are different levels of "being constant".  That is the main
issue here.  An object can be constant only after a runtime
initialisation.  Such level of "constant-ness" is not considered for
template arguments.  To make address of TLS objects acceptable, one
has first to give a preceise and workable extension for the definition
of "constant" expressions as currently defined.

| > | Within a single thread the value never changes.
| >
| > Like in
| >
| >template
| >  struct X { };
| >
| >int main()
| >{
| >   const int i = 2003;
| >   X<&i> x;
| >}
| >
| > ?
| 
| Not sure what you're getting at, since the code is invalid.  I'll
| assume you meant X to take an int* parameter.

yes, sorry, I meant that.

| 
| > In a given program run, &i won't change.  That is just in single
| > thread mode.  Let's solve that first.
| 
| What is there to solve?  I'm not interested in making the above legal
| (is calling main explicitly really disallowed?), but even if I were,
| it doesn't seem closely related to the TLS problem.  I don't see how
| solving your case would help (not that I understand what solving it
| might mean).
| 
| > Extrapolating to a multi-thread mode isn't just changing a word.
| 
| BTW, aren't we wildly OT discussing this here?  Shouldn't it go to a
| committee reflector or comp.std.c++?

Just as OT as the original request for comment.  But, in effect, I
do -not- think that the original request for comment is OT on this list.
To some extent, Boost has components for multi-threading (which is an
extension to the language) and I do not believe that each time we
need to discuss interaction of that extension with the standard
language we ought to leave Boost lists.  

I do not have strong feeling about moving the discussion to the
committee reflector (where the original question was asked).

-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[David Abrahams]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

> | OK, whatever.  I guess I should've said that you can instantiate a
> | template on &k with sensible results.  Whether or not you want to call
> | it a constant is another semantic matter.  I'd call it a constant
> | which evaluates differently in different threads.  
> ^^
>
> And that isn't just a word-game as your message might imply it.

I never meant to imply that it's a word game, just that I'm only
willing to concede "not a constant-ness" for some very narrow
definition of the word "constant."  If you think of threads as being
truly concurrent, the value actually _is_ constant (just different in
different threads).

> | Within a single thread the value never changes.
>
> Like in
>
>template
>  struct X { };
>
>int main()
>{
>   const int i = 2003;
>   X<&i> x;
>}
>
> ?

Not sure what you're getting at, since the code is invalid.  I'll
assume you meant X to take an int* parameter.

> In a given program run, &i won't change.  That is just in single
> thread mode.  Let's solve that first.

What is there to solve?  I'm not interested in making the above legal
(is calling main explicitly really disallowed?), but even if I were,
it doesn't seem closely related to the TLS problem.  I don't see how
solving your case would help (not that I understand what solving it
might mean).

> Extrapolating to a multi-thread mode isn't just changing a word.

BTW, aren't we wildly OT discussing this here?  Shouldn't it go to a
committee reflector or comp.std.c++?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Gabriel Dos Reis]

David Abrahams <[EMAIL PROTECTED]> writes:

| Alexander Terekhov <[EMAIL PROTECTED]> writes:
| 
| >> > David Abrahams <[EMAIL PROTECTED]> writes:
| >> >
| >> > | I disagree with your conclusion.  As I've said elsewhere, &k can be a
| >> > | compile-time constant in the same way that &X::k is a compile-time
| >> > | constant.
| >> >
| >> > Certainly, you've said that.  But that assertion by itself does not
| >> > constitute a proof of the well-foundness of the attempted analogy or
| >> > whether the analogy actually constitutes a proof.
| >> 
| >> It's not intended to be proof in the mathematical sense; I doubt I
| >> have the energy for that ;-), though I think MSVC probably constitutes
| >> an existence proof.
| >
| > Yeah. Indeed: 
| 
| OK, whatever.  I guess I should've said that you can instantiate a
| template on &k with sensible results.  Whether or not you want to call
| it a constant is another semantic matter.  I'd call it a constant
| which evaluates differently in different threads.  
^^

And that isn't just a word-game as your message might imply it.

| Within a single thread the value never changes.

Like in

   template
 struct X { };

   int main()
   {
  const int i = 2003;
  X<&i> x;
   }

?

In a given program run, &i won't change.  That is just in single
thread mode.  Let's solve that first.
Extrapolating to a multi-thread mode isn't just changing a word.


-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[David Abrahams]

Alexander Terekhov <[EMAIL PROTECTED]> writes:

>> > David Abrahams <[EMAIL PROTECTED]> writes:
>> >
>> > | I disagree with your conclusion.  As I've said elsewhere, &k can be a
>> > | compile-time constant in the same way that &X::k is a compile-time
>> > | constant.
>> >
>> > Certainly, you've said that.  But that assertion by itself does not
>> > constitute a proof of the well-foundness of the attempted analogy or
>> > whether the analogy actually constitutes a proof.
>> 
>> It's not intended to be proof in the mathematical sense; I doubt I
>> have the energy for that ;-), though I think MSVC probably constitutes
>> an existence proof.
>
> Yeah. Indeed: 

OK, whatever.  I guess I should've said that you can instantiate a
template on &k with sensible results.  Whether or not you want to call
it a constant is another semantic matter.  I'd call it a constant
which evaluates differently in different threads.  Within a single
thread the value never changes.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[David Abrahams]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

> David Abrahams <[EMAIL PROTECTED]> writes:
>
> | I disagree with your conclusion.  As I've said elsewhere, &k can be a
> | compile-time constant in the same way that &X::k is a compile-time
> | constant.
>
> Certainly, you've said that.  But that assertion by itself does not
> constitute a proof of the well-foundness of the attempted analogy or
> whether the analogy actually constitutes a proof.

It's not intended to be proof in the mathematical sense; I doubt I
have the energy for that ;-), though I think MSVC probably constitutes
an existence proof.

I'm hoping people will "just see" that it's possible based on what
I've said.  I doubt I can explain it any better than I have at this
point.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Gabriel Dos Reis]

Alexander Terekhov <[EMAIL PROTECTED]> writes:

| Ken Hagan wrote:
| 
| [ ... &k ... ]
| 
| > So presumably we are all now in complete agreement, except perhaps
| 
| I, for one, believe strongly that "&k" is nothing but
| 
| "static_cast(pthread_getspecific(__k_key));"
| 
| It *isn't* a compile-time constant (just like &errno isn't a compile
| time constant).

Right now, what you said matches my understanding of the issue.

-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Gabriel Dos Reis]

David Abrahams <[EMAIL PROTECTED]> writes:

| I disagree with your conclusion.  As I've said elsewhere, &k can be a
| compile-time constant in the same way that &X::k is a compile-time
| constant.

Certainly, you've said that.  But that assertion by itself does not
constitute a proof of the well-foundness of the attempted analogy or
whether the analogy actually constitutes a proof.

-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[David Abrahams]

"Ken Hagan" <[EMAIL PROTECTED]> writes:

> Reading various replies, we appear to have a couple of things that
> aren't completely pinned down: the type of "&k" and the implementation
> of TLS.

I think you may be missing the point that in some sense &k doesn't
have to have a single type.  At compile-time it can be manipulated as
though it's a different type of thing from other (non-TLS)
pointers-to-objects, while at runtime it will of course always be an
ordinary pointer.

>  1 If "&k" is a regular pointer to integer and TLS is implemented by
>tweaking page tables for each thread, then "&k" has the same value
>in each thread and C<&k> is the same type, but any member of C<&K>
>that uses its template parameter will behave differently from one
>thread to another.

The behavior you describe above is IMO the only reasonable one, but
IMO we don't need the implementation details (tweaking page tables) in
order to achieve it.

>Is this a problem. I don't think so. Consider...
>
>   __declspec(thread) k
>   int foo() { return k; }
>
>We can easily write a template, C, and instantiate it "C<&k>" and
>have its behaviour vary per-thread, although the value of the
>template parameter is the same.
>
>With this TLS implementation, we can't expose TLS data to another
>thread except by copying it. The workaround is simply to store a
>pointer to the actual data or object.
>
>  2 If "&k" is a regular pointer and TLS is implemented by allocating
>separate blocks for each thread and storing the addresses in a
>register, then "&k" has a different value in each thread and is no
>longer a compile time constant so you can't write the template.

I disagree with your conclusion.  As I've said elsewhere, &k can be a
compile-time constant in the same way that &X::k is a compile-time
constant.  This is simple to accomplish from a conceptual POV, though
existing compilers may need some modification to support it.
Conceptually, the compile-time representation of addresses would have
to be something like this:

   struct address
   {
type t;// the type of object being pointed at
bool thread_local;// whether it's thread-local
unsigned logical_address;
   };

logical addresses would be assigned for TLS entities in the same way
as other "globals."  Typically physical addresses are not determined
until link-time.

>  3 If "&k" is a special pointer, then we can implement TLS either way,
>but we must define a conversion between special and regular pointers.
>For ordinary functions expecting "int*" the compiler simply invokes
>this conversion when passing the argument and no-one gets upset.
>However, for the template case, that conversion is a run-time
>operation so it clearly can't apply.

I don't know what you mean by "special pointer", and I don't see what
argument-passing has to do with it.  It's simply a matter of what code
gets generated to retrieve &k at the compile-time/runtime boundary.
Having different ways to get the address is no different conceptually
from having near and far variables, or variables which are local or in
some other DLL.

> 3a If we allow C<&k>, then "&k" is the offset into the TLS table, the
>instantiated code includes the conversion, and C<&k> is the same
>type in every thread because the offset is the same. It is then
>possible to initialise static variables with the converted value
>of "&k" and the results depend on the thread that ran first. Again,
>we have the same "problem" passing a pointer to a function, so I'm
>not bothered by this.

I don't understand how this is different from the other options above.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Peter Dimov]

Alexander Terekhov wrote:
> Peter Dimov wrote:
>>
>> Ken Hagan wrote:
>>> Peter Dimov wrote:

 &k does not exist yet at compile-time (in a pointer to int form),
 when templates are instantiated.
>>>
>>> It doesn't have to. We're instantiating a template, not calling a
>>> function, so if "&k" has the type "pointer to thread-local int" then
>>> the compiler knows that and can instantiate the appropriate code.
>
> Please define "appropriate code". Please see the added 2 lines below.

[...]

>> template struct C
>> {
>> void f()
>> {
>> std::cout << " p: " << p << ": " << *p << std::endl;
>   static const uintptr_t * P = p;
>   std::cout << " P: " << P << ": " << *P << std::endl;
>> }
>> };

Output:

 p: 00143204: 2024
 P: 00143204: 2024
&k: 00143204: 2024
 p: 00143224: 2036
 P: 00143204: 2024
&k: 00143224: 2036
 p: 00143244: 2012
 P: 00143204: 2024
&k: 00143244: 2012

I must admit that I didn't expect even for p to be different across threads.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Peter Dimov]

Ken Hagan wrote:
[...]
> In implementation terms, pmk is a compile-time constant, so I think it
> could be an acceptable template parameter. On the other hand, the code
> required to extract the integer value is different from the code
> required
> to dereference a normal variable. On the third hand, compilers
> supporting
> TLS already face this problem when I write...
>
> __declspec(thread) int k;
> int* pk = &k;
>
> ...and I don't think being a template parameter adds anything new.

&k does not exist yet at compile-time (in a pointer to int form), when
templates are instantiated.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost