Threads and Static Data

[Craig Black]

"Regan Heath" <regan at netmail.co.nz> wrote in message 
news:fjqu5t$2dvs$1 at digitalmars.com...
> Craig Black wrote:
>> "Regan Heath" <regan at netmail.co.nz> wrote in message 
>> news:fjmigm$vhf$1 at digitalmars.com...
>>> Sean Kelly wrote:
>>>> Regan Heath wrote:
>>>>> Craig Black wrote:
>>>>>> "Regan Heath" <regan at netmail.co.nz> wrote in message 
>>>>>> news:fjjtr4$6g2$1 at 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