Threads and Static Data

["Jérôme M. Berger"]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Craig Black wrote:
> ""Jerome M. Berger"" <jeberger at free.fr> wrote in message 
> news:fjmm2j$18pc$1 at digitalmars.com...
>> Regan Heath wrote:
>>> Jerome M. Berger wrote:
>>>> Regan Heath wrote:
>>>>> 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?
>>>>>
>>>>     But if you want to launch several instances of this thread at the
>>>> same time, your variables won't be local, will they?
>>> What do you mean by "local"?
>>>
>>> If you want a copy of the variables for each thread,
>> That's what is usually meant by "thread local", yes.
>>
>>> make them non-static members of the thread.
>>>
>> As others have said, this only works if you have complete control
>> of your environment. In particular, if you are writing a library and
>> don't know if that library will be used in a single-threaded or
>> multi-threaded environment, then you cannot put any data in the
>> thread class since you won't have access to it in the first place.
>>
>> OTOH, properly designed libraries should store all their data for a
>> given task in a struct (or class) and let the caller manage that
>> struct however he wants (local variable, class member, global
>> variable, whatever). So thread local storage isn't that useful.
> 
> I'm not following you.  Is what you are suggesting just another way to do 
> thread local storage using a data structure that is instantiated each time a 
> thread is instantiated?  Isn't this the exact same thing as the ThreadLocal 
> template provided in Tango?  The bottom line is that data has to be 
> instantiated with each thread.  I don't see a way around this. 
> 
	Caveats:
 - Tango does not work on my platform (Linux 64 bits + gdc) so I'm
not 100% sure of what exactly ThreadLocal does (although I can guess);
 - There were two very different points in my message and I'm not
sure which one you're answering to.

	That being said, I'll try to clarify what I meant:
 - My first point was to illustrate what thread-local storage is for
as opposed to instance variables in the thread class. Another
illustration would be to point to this Wikipedia page:
http://en.wikipedia.org/wiki/Thread-local_storage

 - My second point was that a specific thread-local storage
mechanism isn't really needed if the libraries are properly
designed. Properly designed libraries should have an "Init" or
"Open" function that returns a handle, then all other functions
should take that handle as a parameter(*). For such libraries, local
variables are enough and a mechanism such as described in the
Wikipedia page is overkill. Therefore, I don't think it's really
necessary to add it to the core language: having it implemented in a
library is enough for the rare cases where it's impossible to do
without.

		Jerome

(*) This can of course be done by returning some object instance and
calling methods of this object instead of passing a handle around
explicitly.

- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger at free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger at jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHYDmBd0kWM4JG3k8RAuxMAJ9nLLkXgW4LtBLqFpua9lh6ssAsNgCgu8jh
CKBNGhNHyatM1TwwhDFc7PU=
=T5qA
-----END PGP SIGNATURE-----