www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Threads and Static Data

reply "Craig Black" <craigblack2 cox.net> writes:
I'm in the process of hashing out a design for multi-core support for a 
large API developed by myself and a couple other people.  I realized that 
static data can be problematic for multiple threads.  In many cases, it 
seems that static data should be instantiated on a per-thread basis.  My 
solution to this problem is to use a template class called "Threaded" that 
instantiates data for each thread.

static Threaded!(int) x;

Then to access the value, there would have to be a thread ID passed into it. 
So to increment the value you would have.

int temp = x.get(threadID);
x.set(threadID, temp+1);

(Or, I guess you could use a pointer.)

int *ptr = x.getptr(threadID);
(*ptr)++;

This solution will do the job, but it is a little clumsy.  This seems like 
this is a common problem that warrants better syntax.  Ideally, I would like 
to be able access a "threaded" variable just like any other so that the 
above example is simply "x++".  I don't have extensive experience with D 
templates and operator overloading.  It it possible to make this work 
transparently with all operators?  I want to support all basic types as well 
as structs and classes.  Could someone with more experience fill me in on 
the caveats involved in implementing something like this?  Has anyone else 
already solved this problem?  This seems like a feature that should be 
included in the standard library.

-Craig
Dec 09 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Craig Black wrote:

 I'm in the process of hashing out a design for multi-core support for a 
 large API developed by myself and a couple other people.  I realized 
 that static data can be problematic for multiple threads.  In many 
 cases, it seems that static data should be instantiated on a per-thread 
 basis.  My solution to this problem is to use a template class called 
 "Threaded" that instantiates data for each thread.
 
 static Threaded!(int) x;
 
 Then to access the value, there would have to be a thread ID passed into 
 it. So to increment the value you would have.
 
 int temp = x.get(threadID);
 x.set(threadID, temp+1);
 
 (Or, I guess you could use a pointer.)
 
 int *ptr = x.getptr(threadID);
 (*ptr)++;
 
 This solution will do the job, but it is a little clumsy.  This seems 
 like this is a common problem that warrants better syntax.  Ideally, I 
 would like to be able access a "threaded" variable just like any other 
 so that the above example is simply "x++".  I don't have extensive 
 experience with D templates and operator overloading.  It it possible to 
 make this work transparently with all operators?  I want to support all 
 basic types as well as structs and classes.  Could someone with more 
 experience fill me in on the caveats involved in implementing something 
 like this?  Has anyone else already solved this problem?  This seems 
 like a feature that should be included in the standard library.
 
 -Craig


Tango has tango.core.Thread.ThreadLocal for thrad-local storage. I don't 
know about phobos, but if it's not there it should be.
Dec 09 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fjip5u$2uud$1 digitalmars.com...

 Craig Black wrote:

 I'm in the process of hashing out a design for multi-core support for a 
 large API developed by myself and a couple other people.  I realized that 
 static data can be problematic for multiple threads.  In many cases, it 
 seems that static data should be instantiated on a per-thread basis.  My 
 solution to this problem is to use a template class called "Threaded" 
 that instantiates data for each thread.

 static Threaded!(int) x;

 Then to access the value, there would have to be a thread ID passed into 
 it. So to increment the value you would have.

 int temp = x.get(threadID);
 x.set(threadID, temp+1);

 (Or, I guess you could use a pointer.)

 int *ptr = x.getptr(threadID);
 (*ptr)++;

 This solution will do the job, but it is a little clumsy.  This seems 
 like this is a common problem that warrants better syntax.  Ideally, I 
 would like to be able access a "threaded" variable just like any other so 
 that the above example is simply "x++".  I don't have extensive 
 experience with D templates and operator overloading.  It it possible to 
 make this work transparently with all operators?  I want to support all 
 basic types as well as structs and classes.  Could someone with more 
 experience fill me in on the caveats involved in implementing something 
 like this?  Has anyone else already solved this problem?  This seems like 
 a feature that should be included in the standard library.

 -Craig


 Tango has tango.core.Thread.ThreadLocal for thrad-local storage. I don't 
 know about phobos, but if it's not there it should be.


Suite!  I think I've seen the term "thread local", but it never occured to 
me what it meant.  Goes to show you how green I am when it comes to 
threading.  I'll check it out.  Thanks.

-Craig
Dec 10 2007
parent reply Sean Kelly <sean f4.ca> writes:
Craig Black wrote:

 
 Suite!  I think I've seen the term "thread local", but it never occured to 
 me what it meant.  Goes to show you how green I am when it comes to 
 threading.  I'll check it out.  Thanks.


For what it's worth, some C/C++ compilers have "thread local" as a 
storage class.  I've proposed adding this to D before, but there seemed 
to be no interest at the time.


Sean
Dec 10 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when it 
 comes to threading.  I'll check it out.  Thanks.


 
 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there seemed 
 to be no interest at the time.


If I want thread local storage I just add the variables as static 
members of the class I've derived from Thread.

Does thread local storage give us some advantage over that?

R
Dec 10 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when it 
 comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 
 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.


Yup.  static ThreadLocal!(T) myVar;


 Does thread local storage give us some advantage over that?


If I understand you correctly, ThreadLocal(T) is simply a front-end for 
the Thread.get/setLocal routines.  It provides type safety and 
convenience but stores the data in a dynamically allocated object, and 
the one allocation per thread may or may not be something you want to 
pay for.  This is why both methods are available.


Sean
Dec 10 2007
parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:

 Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.


 
 Yup.  static ThreadLocal!(T) myVar;


Oops, I misunderstood the question.  There's one big problems with this 
approach: the object representing the main application thread cannot be 
modified.


Sean
Dec 10 2007
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote in message 
news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never occured 
 to me what it meant.  Goes to show you how green I am when it comes to 
 threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there seemed 
 to be no interest at the time.


 If I want thread local storage I just add the variables as static members 
 of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


Storing all your static data for everything in a thread class is not ideal 
from a software design perspective IMO.
Dec 10 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never occured 
 to me what it meant.  Goes to show you how green I am when it comes to 
 threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there seemed 
 to be no interest at the time.


 If I want thread local storage I just add the variables as static members 
 of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 
 Storing all your static data for everything in a thread class is not ideal 
 from a software design perspective IMO. 


Why not?

The way I see it members of a thread class are essentially the same 
thing as global variables in a program.

The program is just the first thread, and it's member variables are 
global variables.

The difference is that any thread you create has public access to the 
program/main threads member/global variables, which is actually worse in 
terms of encapsulation than using thread classes and member variables.

So, I reckon if you want "a variable which is private to a thread" why 
not just make it a member of your thread class.

Regan
Dec 11 2007
parent reply Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO. 


 
 Why not?
 
 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.
 
 The program is just the first thread, and it's member variables are 
 global variables.
 
 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse in 
 terms of encapsulation than using thread classes and member variables.
 
 So, I reckon if you want "a variable which is private to a thread" why 
 not just make it a member of your thread class.


A library designer doesn't always have the ability to dictate what goes 
in a thread class, or necessarily even knows whether the library will be 
used in a multithreaded program.


Sean
Dec 11 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Sean Kelly wrote:

 Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO. 


 Why not?

 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.

 The program is just the first thread, and it's member variables are 
 global variables.

 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse 
 in terms of encapsulation than using thread classes and member variables.

 So, I reckon if you want "a variable which is private to a thread" why 
 not just make it a member of your thread class.


 
 A library designer doesn't always have the ability to dictate what goes 
 in a thread class, or necessarily even knows whether the library will be 
 used in a multithreaded program.


That's true, if the library uses global variables.  Otherwise you can 
stick the libraries data structures/classes/etc into the thread as members.

Right?  Or am I missing something.

Regan
Dec 11 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 Sean Kelly wrote:

 Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am 
 when it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO. 


 Why not?

 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.

 The program is just the first thread, and it's member variables are 
 global variables.

 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse 
 in terms of encapsulation than using thread classes and member 
 variables.

 So, I reckon if you want "a variable which is private to a thread" 
 why not just make it a member of your thread class.


 A library designer doesn't always have the ability to dictate what 
 goes in a thread class, or necessarily even knows whether the library 
 will be used in a multithreaded program.


 
 That's true, if the library uses global variables.  Otherwise you can 
 stick the libraries data structures/classes/etc into the thread as members.
 
 Right?  Or am I missing something.


That's pretty much it.  Sometimes implementation-level static data isn't 
used in a way that makes it easy to embed in a user-level handle.  Or it 
may be that user-level granularity is just plain wrong.  Some cached 
data, for example, may be best applied as common to all users, but 
protecting it via a mutex could cause entirely different problems.


Sean
Dec 11 2007
prev sibling parent reply "Craig Black" <cblack ara.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote in message 
news:fjmigm$vhf$1 digitalmars.com...

 Sean Kelly wrote:

 Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO.


 Why not?

 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.

 The program is just the first thread, and it's member variables are 
 global variables.

 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse in 
 terms of encapsulation than using thread classes and member variables.

 So, I reckon if you want "a variable which is private to a thread" why 
 not just make it a member of your thread class.


 A library designer doesn't always have the ability to dictate what goes 
 in a thread class, or necessarily even knows whether the library will be 
 used in a multithreaded program.


 That's true, if the library uses global variables.  Otherwise you can 
 stick the libraries data structures/classes/etc into the thread as 
 members.

 Right?  Or am I missing something.

 Regan


Think of multiple plug-in librariess to an application.  The application is 
responsible for creating the threads.  In order for the plug-ins to add 
their respective thread local data to the thread class, they have to inherit 
it.  So now plug-in A has class ThreadA and plugin B has class ThreadB. 
Which class should the application instantiate to start a thread?

-Craig
Dec 12 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjmigm$vhf$1 digitalmars.com...

 Sean Kelly wrote:

 Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO.


 Why not?

 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.

 The program is just the first thread, and it's member variables are 
 global variables.

 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse in 
 terms of encapsulation than using thread classes and member variables.

 So, I reckon if you want "a variable which is private to a thread" why 
 not just make it a member of your thread class.


 A library designer doesn't always have the ability to dictate what goes 
 in a thread class, or necessarily even knows whether the library will be 
 used in a multithreaded program.


 That's true, if the library uses global variables.  Otherwise you can 
 stick the libraries data structures/classes/etc into the thread as 
 members.

 Right?  Or am I missing something.

 Regan


 
 Think of multiple plug-in librariess to an application.  The application is 
 responsible for creating the threads.  In order for the plug-ins to add 
 their respective thread local data to the thread class, they have to inherit 
 it.  So now plug-in A has class ThreadA and plugin B has class ThreadB. 
 Which class should the application instantiate to start a thread?


Well, I was assuming the plug in library had some class or struct and 
some methods or functions to call on those objects... but you're 
suggesting the plug in publishes a thread class?

That's a bit weird, but ok.  I would create a ThreadC (derived from the 
Thread base) class and have a reference to both ThreadA and ThreadB in 
it.  I then instantiate ThreadC for each thread I need, where the 
constructor for ThreadC instantiates but does not 'start' ThreadA or 
ThreadB.

So, each and every ThreadC object contains a copy of the data that 
ThreadA and ThreadB contain, or rather a copy of the data the plug in 
requires.

Regan
Dec 13 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote in message 
news:fjqu5t$2dvs$1 digitalmars.com...

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjmigm$vhf$1 digitalmars.com...

 Sean Kelly wrote:

 Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO.


 Why not?

 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.

 The program is just the first thread, and it's member variables are 
 global variables.

 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse 
 in terms of encapsulation than using thread classes and member 
 variables.

 So, I reckon if you want "a variable which is private to a thread" why 
 not just make it a member of your thread class.


 A library designer doesn't always have the ability to dictate what goes 
 in a thread class, or necessarily even knows whether the library will 
 be used in a multithreaded program.


 That's true, if the library uses global variables.  Otherwise you can 
 stick the libraries data structures/classes/etc into the thread as 
 members.

 Right?  Or am I missing something.

 Regan


 Think of multiple plug-in librariess to an application.  The application 
 is responsible for creating the threads.  In order for the plug-ins to 
 add their respective thread local data to the thread class, they have to 
 inherit it.  So now plug-in A has class ThreadA and plugin B has class 
 ThreadB. Which class should the application instantiate to start a 
 thread?


 Well, I was assuming the plug in library had some class or struct and some 
 methods or functions to call on those objects... but you're suggesting the 
 plug in publishes a thread class?

 That's a bit weird, but ok.  I would create a ThreadC (derived from the 
 Thread base) class and have a reference to both ThreadA and ThreadB in it. 
 I then instantiate ThreadC for each thread I need, where the constructor 
 for ThreadC instantiates but does not 'start' ThreadA or ThreadB.

 So, each and every ThreadC object contains a copy of the data that ThreadA 
 and ThreadB contain, or rather a copy of the data the plug in requires.

 Regan


What you suggest will not work if plug-in A was created by company A and 
plug-in B was created by company B.  They know nothing about each other and 
do not release source code.  Inheritance is not a good solution here.

A system that would work is one where the base thread class has a static 
container of object factories.  Then each plug-in could submit their object 
factory to the base thread class.  Then, object factory A could instantiate 
class A to support plug-in A, and object factory B could instantiate class B 
to support plug-in B, etc.  The object factories would be called whenever a 
thread is instantiated.

Most likely, the ThreadLocal template in Tango probably uses a system 
similar to this.  I'm not sure about the details though.

-Craig
Dec 13 2007
parent Sean Kelly <sean f4.ca> writes:
Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjqu5t$2dvs$1 digitalmars.com...

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjmigm$vhf$1 digitalmars.com...

 Sean Kelly wrote:

 Regan Heath wrote:

 Craig Black wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fjjtr4$6g2$1 digitalmars.com...

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never 
 occured to me what it meant.  Goes to show you how green I am when 
 it comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a 
 storage class.  I've proposed adding this to D before, but there 
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static 
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?

 R


 Storing all your static data for everything in a thread class is not 
 ideal from a software design perspective IMO.


 Why not?

 The way I see it members of a thread class are essentially the same 
 thing as global variables in a program.

 The program is just the first thread, and it's member variables are 
 global variables.

 The difference is that any thread you create has public access to the 
 program/main threads member/global variables, which is actually worse 
 in terms of encapsulation than using thread classes and member 
 variables.

 So, I reckon if you want "a variable which is private to a thread" why 
 not just make it a member of your thread class.


 A library designer doesn't always have the ability to dictate what goes 
 in a thread class, or necessarily even knows whether the library will 
 be used in a multithreaded program.


 That's true, if the library uses global variables.  Otherwise you can 
 stick the libraries data structures/classes/etc into the thread as 
 members.

 Right?  Or am I missing something.

 Regan


 Think of multiple plug-in librariess to an application.  The application 
 is responsible for creating the threads.  In order for the plug-ins to 
 add their respective thread local data to the thread class, they have to 
 inherit it.  So now plug-in A has class ThreadA and plugin B has class 
 ThreadB. Which class should the application instantiate to start a 
 thread?


 Well, I was assuming the plug in library had some class or struct and some 
 methods or functions to call on those objects... but you're suggesting the 
 plug in publishes a thread class?

 That's a bit weird, but ok.  I would create a ThreadC (derived from the 
 Thread base) class and have a reference to both ThreadA and ThreadB in it. 
 I then instantiate ThreadC for each thread I need, where the constructor 
 for ThreadC instantiates but does not 'start' ThreadA or ThreadB.

 So, each and every ThreadC object contains a copy of the data that ThreadA 
 and ThreadB contain, or rather a copy of the data the plug in requires.

 Regan


 
 What you suggest will not work if plug-in A was created by company A and 
 plug-in B was created by company B.  They know nothing about each other and 
 do not release source code.  Inheritance is not a good solution here.
 
 A system that would work is one where the base thread class has a static 
 container of object factories.  Then each plug-in could submit their object 
 factory to the base thread class.  Then, object factory A could instantiate 
 class A to support plug-in A, and object factory B could instantiate class B 
 to support plug-in B, etc.  The object factories would be called whenever a 
 thread is instantiated.
 
 Most likely, the ThreadLocal template in Tango probably uses a system 
 similar to this.  I'm not sure about the details though.


It's a bit simpler than this right now.  It would be easy enough to let 
the user provide delegates to auto-construct data on thread 
initialization, but given that these could throw, I'm hesitant to do so.


Sean
Dec 13 2007
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never
 occured to me what it meant.  Goes to show you how green I am when it
 comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a
 storage class.  I've proposed adding this to D before, but there
 seemed to be no interest at the time.


 
 If I want thread local storage I just add the variables as static
 members of the class I've derived from Thread.
 
 Does thread local storage give us some advantage over that?


	But if you want to launch several instances of this thread at the
same time, your variables won't be local, will they?

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHXYrXd0kWM4JG3k8RArl2AJ47m7+I351Uzsq5d5IPztpmOeNNXACdEaSf
WLPKfctUHx5gvl3b6nFMxSk=
=06vK
-----END PGP SIGNATURE-----
Dec 10 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Jérôme M. Berger wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never
 occured to me what it meant.  Goes to show you how green I am when it
 comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a
 storage class.  I've proposed adding this to D before, but there
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?


 	But if you want to launch several instances of this thread at the
 same time, your variables won't be local, will they?


What do you mean by "local"?

If you want a copy of the variables for each thread, make them 
non-static members of the thread.

Regan
Dec 11 2007
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath wrote:

 Jérôme M. Berger wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never
 occured to me what it meant.  Goes to show you how green I am when it
 comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a
 storage class.  I've proposed adding this to D before, but there
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?


     But if you want to launch several instances of this thread at the
 same time, your variables won't be local, will they?


 
 What do you mean by "local"?
 
 If you want a copy of the variables for each thread,


	That's what is usually meant by "thread local", yes.


 make them non-static members of the thread.
 


	As others have said, this only works if you have complete control
of your environment. In particular, if you are writing a library and
don't know if that library will be used in a single-threaded or
multi-threaded environment, then you cannot put any data in the
thread class since you won't have access to it in the first place.

	OTOH, properly designed libraries should store all their data for a
given task in a struct (or class) and let the caller manage that
struct however he wants (local variable, class member, global
variable, whatever). So thread local storage isn't that useful.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHXtuTd0kWM4JG3k8RAscyAKCqAJP8MVnF6Qzbukril7bMgH8sYgCePrCC
gbNfsqvWLQdNpOaTVm1liOs=
=DurB
-----END PGP SIGNATURE-----
Dec 11 2007
parent reply "Craig Black" <cblack ara.com> writes:
""Jérôme M. Berger"" <jeberger free.fr> wrote in message 
news:fjmm2j$18pc$1 digitalmars.com...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Regan Heath wrote:

 Jérôme M. Berger wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never
 occured to me what it meant.  Goes to show you how green I am when it
 comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a
 storage class.  I've proposed adding this to D before, but there
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?


     But if you want to launch several instances of this thread at the
 same time, your variables won't be local, will they?


 What do you mean by "local"?

 If you want a copy of the variables for each thread,


 That's what is usually meant by "thread local", yes.


 make them non-static members of the thread.


 As others have said, this only works if you have complete control
 of your environment. In particular, if you are writing a library and
 don't know if that library will be used in a single-threaded or
 multi-threaded environment, then you cannot put any data in the
 thread class since you won't have access to it in the first place.

 OTOH, properly designed libraries should store all their data for a
 given task in a struct (or class) and let the caller manage that
 struct however he wants (local variable, class member, global
 variable, whatever). So thread local storage isn't that useful.


I'm not following you.  Is what you are suggesting just another way to do 
thread local storage using a data structure that is instantiated each time a 
thread is instantiated?  Isn't this the exact same thing as the ThreadLocal 
template provided in Tango?  The bottom line is that data has to be 
instantiated with each thread.  I don't see a way around this.
Dec 12 2007
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Craig Black wrote:

 ""Jerome M. Berger"" <jeberger free.fr> wrote in message 
 news:fjmm2j$18pc$1 digitalmars.com...

 Regan Heath wrote:

 Jerome M. Berger wrote:

 Regan Heath wrote:

 Sean Kelly wrote:

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never
 occured to me what it meant.  Goes to show you how green I am when it
 comes to threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a
 storage class.  I've proposed adding this to D before, but there
 seemed to be no interest at the time.


 If I want thread local storage I just add the variables as static
 members of the class I've derived from Thread.

 Does thread local storage give us some advantage over that?


     But if you want to launch several instances of this thread at the
 same time, your variables won't be local, will they?


 What do you mean by "local"?

 If you want a copy of the variables for each thread,


 That's what is usually meant by "thread local", yes.


 make them non-static members of the thread.


 As others have said, this only works if you have complete control
 of your environment. In particular, if you are writing a library and
 don't know if that library will be used in a single-threaded or
 multi-threaded environment, then you cannot put any data in the
 thread class since you won't have access to it in the first place.

 OTOH, properly designed libraries should store all their data for a
 given task in a struct (or class) and let the caller manage that
 struct however he wants (local variable, class member, global
 variable, whatever). So thread local storage isn't that useful.


 
 I'm not following you.  Is what you are suggesting just another way to do 
 thread local storage using a data structure that is instantiated each time a 
 thread is instantiated?  Isn't this the exact same thing as the ThreadLocal 
 template provided in Tango?  The bottom line is that data has to be 
 instantiated with each thread.  I don't see a way around this. 
 


	Caveats:
 - Tango does not work on my platform (Linux 64 bits + gdc) so I'm
not 100% sure of what exactly ThreadLocal does (although I can guess);
 - There were two very different points in my message and I'm not
sure which one you're answering to.

	That being said, I'll try to clarify what I meant:
 - My first point was to illustrate what thread-local storage is for
as opposed to instance variables in the thread class. Another
illustration would be to point to this Wikipedia page:
http://en.wikipedia.org/wiki/Thread-local_storage

 - My second point was that a specific thread-local storage
mechanism isn't really needed if the libraries are properly
designed. Properly designed libraries should have an "Init" or
"Open" function that returns a handle, then all other functions
should take that handle as a parameter(*). For such libraries, local
variables are enough and a mechanism such as described in the
Wikipedia page is overkill. Therefore, I don't think it's really
necessary to add it to the core language: having it implemented in a
library is enough for the rare cases where it's impossible to do
without.

		Jerome

(*) This can of course be done by returning some object instance and
calling methods of this object instead of passing a handle around
explicitly.

- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHYDmBd0kWM4JG3k8RAuxMAJ9nLLkXgW4LtBLqFpua9lh6ssAsNgCgu8jh
CKBNGhNHyatM1TwwhDFc7PU=
=T5qA
-----END PGP SIGNATURE-----
Dec 12 2007
next sibling parent "Craig Black" <cblack ara.com> writes:
 - My second point was that a specific thread-local storage
 mechanism isn't really needed if the libraries are properly
 designed. Properly designed libraries should have an "Init" or
 "Open" function that returns a handle, then all other functions
 should take that handle as a parameter(*). For such libraries, local
 variables are enough and a mechanism such as described in the
 Wikipedia page is overkill. Therefore, I don't think it's really
 necessary to add it to the core language: having it implemented in a
 library is enough for the rare cases where it's impossible to do
 without.


Ok, you are saying it's not necessary to make it part of the language.  You 
are right, this can be done pretty well without language support.  It just 
requires a little more thought.  This solution is still called thread-local 
storage I think even if it's not a language feature.
Dec 12 2007
prev sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Jérôme M. Berger wrote:

  - My first point was to illustrate what thread-local storage is for
 as opposed to instance variables in the thread class. Another
 illustration would be to point to this Wikipedia page:
 http://en.wikipedia.org/wiki/Thread-local_storage


I think the short explaination is that thread local storage is required 
when you want a separate copy of any _global_ variable for each thread. 
  If you have no global varaibles, you don't need it.

'errno' described in the wikipedia page is the classic example.  It is a 
global variable that many unrelated[1] ANSI C functions will set on 
error.  If it was not global how would these functions access it in 
order to set it.  If it was not global how would you know where it was 
in order to check it.

errno and those ANSI functions are like static members of an "ANSI" 
class which is instantiated when your program runs.  Imagine now what 
would happen if they were non static members of that class.  Instead of 
having only one copy of errno you would have one per instance of "ANSI", 
meaning you could instantiate a different one for each thread you started.

Problem solved, not need for thread local storage or any other mechanism 
for ensuring separate copies of global variables per thread.

The same logic can be applied to any other library you care to name, if 
it has an errno style variable then _it_ will need to use thread local 
storage, if it doesn't it's not thread safe[3], period.

On the other hand if the library encapsulates all it's variables in a 
class or struct[2] then you are free to have a separate instance of the 
class or struct per thread, typically as a member of your thread class.

Regan

[1]unrelated in that they perform many and varied tasks, related in that 
they are all ANSI C functions and they all use errno.

[2]unless they are static members of a class, as this gives only one 
copy per process and again thread local storage has to be used, or it 
will never be thread safe[3].

[3]unless the variable is protected by synchronisation constructs like 
critical sections or mutexes.
Dec 13 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Regan Heath wrote:

 
 On the other hand if the library encapsulates all it's variables in a 
 class or struct[2] then you are free to have a separate instance of the 
 class or struct per thread, typically as a member of your thread class.


The only catch being that you would either have to pass that variable 
into all relevant calls in the library, or the library would have to 
maintain a thread-local reference to it.


Sean
Dec 13 2007
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath wrote:

 Jérôme M. Berger wrote:

  - My first point was to illustrate what thread-local storage is for
 as opposed to instance variables in the thread class. Another
 illustration would be to point to this Wikipedia page:
 http://en.wikipedia.org/wiki/Thread-local_storage


 
 I think the short explaination is that thread local storage is required
 when you want a separate copy of any _global_ variable for each thread.
  If you have no global varaibles, you don't need it.
 


	Correct.


 ...
 On the other hand if the library encapsulates all it's variables in a
 class or struct[2] then you are free to have a separate instance of the
 class or struct per thread, typically as a member of your thread class.
 


	This was my second point, yes.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHYYeLd0kWM4JG3k8RAjmZAJ9TrkrQWsY8pLFiiL7QaAlP4Jaw2wCfeMvm
bFU0D7dHNx6igQpKAy4gNxY=
=3KGC
-----END PGP SIGNATURE-----
Dec 13 2007
prev sibling parent "Craig Black" <cblack ara.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:fjjp7l$2t9c$2 digitalmars.com...

 Craig Black wrote:

 Suite!  I think I've seen the term "thread local", but it never occured 
 to me what it meant.  Goes to show you how green I am when it comes to 
 threading.  I'll check it out.  Thanks.


 For what it's worth, some C/C++ compilers have "thread local" as a storage 
 class.  I've proposed adding this to D before, but there seemed to be no 
 interest at the time.


 Sean


It would definitely be convenient.
Dec 10 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Craig Black wrote:

 
 This solution will do the job, but it is a little clumsy.  This seems 
 like this is a common problem that warrants better syntax.  Ideally, I 
 would like to be able access a "threaded" variable just like any other 
 so that the above example is simply "x++".


See tango.core.Thread: Thread.get/setLocal or ThreadLocal(T).


Sean
Dec 10 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
Sean Kelly schrieb:

 Craig Black wrote:

 This solution will do the job, but it is a little clumsy.  This seems
 like this is a common problem that warrants better syntax.  Ideally, I
 would like to be able access a "threaded" variable just like any other
 so that the above example is simply "x++".


 
 See tango.core.Thread: Thread.get/setLocal or ThreadLocal(T).
 
 
 Sean


See also
http://dsource.org/projects/tango/wiki/ChapterThreading#ThreadLocalStorageTLS
Dec 10 2007