Threads and Static Data

[Regan Heath]

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