Threads and Static Data

[Craig Black]

"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?

-Craig