Threads and Static Data

[Sean Kelly]

Craig Black wrote:
> "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.

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