Threads and Static Data

[Sean Kelly]

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.


Sean