www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the deal with __thread?

reply Don Clugston <dac nospam.com> writes:
IIRC it was used prior to 2.030. In the spec, it is in the keyword list, 
and it's also listed in the "Migrating to shared" article. That's all. 
There are a small number of uses of it in the DMD test suite.

Is it still valid? Is it useful? Or has everyone forgotten that it still 
exists?
Nov 14 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Nov 14, 2012, at 6:26 AM, Don Clugston <dac nospam.com> wrote:

 IIRC it was used prior to 2.030. In the spec, it is in the keyword =

all. There are a small number of uses of it in the DMD test suite.
=20
 Is it still valid? Is it useful? Or has everyone forgotten that it =

I think __thread was for explicit TLS before TLS became the default. I = don't see a continued use for it.=
Nov 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2012 12:06 PM, Sean Kelly wrote:
 On Nov 14, 2012, at 6:26 AM, Don Clugston <dac nospam.com> wrote:

 IIRC it was used prior to 2.030. In the spec, it is in the keyword list,
 and it's also listed in the "Migrating to shared" article. That's all.
 There are a small number of uses of it in the DMD test suite.

 Is it still valid? Is it useful? Or has everyone forgotten that it still
 exists?

I think __thread was for explicit TLS before TLS became the default. I don't see a continued use for it.

Sean's right.
Nov 14 2012
parent reply Don Clugston <dac nospam.com> writes:
On 14/11/12 23:16, Walter Bright wrote:
 On 11/14/2012 12:06 PM, Sean Kelly wrote:
 On Nov 14, 2012, at 6:26 AM, Don Clugston <dac nospam.com> wrote:

 IIRC it was used prior to 2.030. In the spec, it is in the keyword list,
 and it's also listed in the "Migrating to shared" article. That's all.
 There are a small number of uses of it in the DMD test suite.

 Is it still valid? Is it useful? Or has everyone forgotten that it still
 exists?

I think __thread was for explicit TLS before TLS became the default. I don't see a continued use for it.

Sean's right.

Good, that's what I thought. Lets remove it from the spec, and deprecate it. There is probably no extant code that uses it, outside of the test suite. However, there is one case in the test suite which is unclear to me: extern(C) __thread int x; Is there any other way to do this?
Nov 15 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-15 11:28, Don Clugston wrote:

 However, there is one case in the test suite which is unclear to me:

 extern(C) __thread int x;

 Is there any other way to do this?

extern (C) int x; "extern(C)" doesn't make it global. -- /Jacob Carlborg
Nov 15 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/15/2012 2:28 AM, Don Clugston wrote:
 However, there is one case in the test suite which is unclear to me:

 extern(C) __thread int x;

 Is there any other way to do this?

extern(C) int x;
Nov 15 2012
parent reply Don Clugston <dac nospam.com> writes:
On 15/11/12 11:54, Walter Bright wrote:
 On 11/15/2012 2:28 AM, Don Clugston wrote:
 However, there is one case in the test suite which is unclear to me:

 extern(C) __thread int x;

 Is there any other way to do this?

extern(C) int x;

What about extern(C) variables which are not thread local? (which I think would be the normal case). Then from a C header, extern(C) int x; must become: extern(C) __gshared int x; in D. It's a very rare case, I guess, but it's one of those situations where D code silently has different behaviour from identical C code.
Nov 15 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 15-11-2012 15:42, Don Clugston wrote:
 On 15/11/12 11:54, Walter Bright wrote:
 On 11/15/2012 2:28 AM, Don Clugston wrote:
 However, there is one case in the test suite which is unclear to me:

 extern(C) __thread int x;

 Is there any other way to do this?

extern(C) int x;

What about extern(C) variables which are not thread local? (which I think would be the normal case). Then from a C header, extern(C) int x; must become: extern(C) __gshared int x; in D. It's a very rare case, I guess, but it's one of those situations where D code silently has different behaviour from identical C code.

I think most people are aware of this 'quirk' from what I've seen in binding projects, so it's probably not a big deal. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 15 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/15/2012 6:46 AM, Alex Rønne Petersen wrote:
 I think most people are aware of this 'quirk' from what I've seen in binding
 projects, so it's probably not a big deal.

Also, remember that C code can now have thread local globals, too. Both are expressible in D, it's just that the default is reversed.
Nov 15 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/15/2012 6:42 AM, Don Clugston wrote:
 On 15/11/12 11:54, Walter Bright wrote:
 On 11/15/2012 2:28 AM, Don Clugston wrote:
 However, there is one case in the test suite which is unclear to me:

 extern(C) __thread int x;

 Is there any other way to do this?

extern(C) int x;

What about extern(C) variables which are not thread local? (which I think would be the normal case). Then from a C header, extern(C) int x; must become: extern(C) __gshared int x;

That's right. extern(C) doesn't change the storage class.
 in D. It's a very rare case, I guess, but it's one of those situations where D
 code silently has different behaviour from identical C code.

Nov 15 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 15 November 2012 at 14:42:32 UTC, Don Clugston wrote:
 in D. It's a very rare case, I guess, but it's one of those 
 situations where D code silently has different behaviour from 
 identical C code.

extern(C) int x; is not C code. :P
Nov 16 2012