Threads and Static Data

[Regan Heath]

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