Threads and Static Data

[Sean Kelly]

Regan Heath wrote:
> 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.

That's pretty much it.  Sometimes implementation-level static data isn't 
used in a way that makes it easy to embed in a user-level handle.  Or it 
may be that user-level granularity is just plain wrong.  Some cached 
data, for example, may be best applied as common to all users, but 
protecting it via a mutex could cause entirely different problems.


Sean