Talk:Thread-local storage

Improving the Java Example
The java example should probably show a static ThreadLocal. Although non-static ThreadLocal objects can be created, it's not the common use case and can lead to issues. See this excellent post on the issue: http://www.0xcafefeed.com/2004/06/of-non-static-threadlocals-and-memory/ —Preceding unsigned comment added by 64.81.48.183 (talk) 17:01, 22 July 2009 (UTC)

Adding more OS & Language sections
Information on other operating systems would be interesting. Shinobu 01:44, 26 Mar 2005 (UTC)

TLS using POSIX? TLS in Perl? Shinobu 10:20, 16 May 2005 (UTC)

Capitalisation
This should be 'thread-local storage'. At the very least, lower case l and s. I don't know how to rename a page though. --Stevage 02:52, 1 December 2005 (UTC)
 * You're absolutely right. Fortunately I do know how to rename a page. Shinobu 10:42, 2 December 2005 (UTC)
 * Well, thanks for doing it, care to share? :) --Stevage 13:30, 2 December 2005 (UTC)
 * There's a tab to the right of the "history"-tab (to the left of the "(un)watch"-tab). Be sure to invoke it from the article-page, not from the talk-page, otherwise only the talk-page gets renamed. The nice thing about this way of renaming an article compared to a cut and paste move is that a) all the article history will be moved along and b) a redirect from the old name is created automatically. Shinobu 11:09, 3 December 2005 (UTC)
 * Thank you! --Stevage 14:16, 3 December 2005 (UTC)
 * どう致しまして! Shinobu 18:56, 3 December 2005 (UTC)

Implementation sections
Is it really necessary to detail the specific implementations for each platform? I'm relatively new to Wikipedia, but it seems to me that such information is beyond the scope of this encyclopedia. Parklandspanaway 20:08, 11 November 2006 (UTC)
 * I'm sure you can find people here on both sides of that issue. My take is that the examples in this article are acceptable because they are fairly concise and there are not an excessive number of them. —Doug Bell talk•contrib 06:51, 11 November 2006 (UTC)

Wouldn't it more suitable to provide a single example, then provide links to external documents that can give examples for each implementation? My concern is that this article will continue to grow as users add examples for every language they can think of and cause this article to become bloated and unreadable. —Parklandspanaway 20:12, 11 November 2006 (UTC)


 * My response is that we can refactor the article if that happens. That same situation has occurred on many other articles before, with a common remedy being to separate the example implementations into their own article, or delete them.  I think they have value in that you can see in a fairly concise way (which is not what you get by refering to external documentation) how the various language implementations differ.  Anyway, I'm not trying to argue this point because I'm against any change, just giving you my opinion on the matter. —Doug Bell talk•contrib 20:16, 11 November 2006 (UTC)

The explanation of Windows implementation is incorrect. While there exists an API consisting of TlsAlloc/TlsGetValue/TlsSetValue/TlsSetValue, these API calls are a separate mechanism that has little to do with what happens behind __declspec(thread). TlsXXX are managed manually by programmer to store some pointer data in memory pointed to by different selector (namely, fs) - special data segment is allocated that behaves differently; no flat-model pointer can point to these variables, since they are stored in different segment than rest of program's memory (selectors cs, ss, ds, es). Insted, __declspec(thread) creates a special section in executable, which is managed differently by the operating system and each thread is given a separate copy of tls section pages (page tables differ for different threads). This memory lies in the same selector as code and data and can therefore be pointed to and used transparently as general purpose memory. Moreover, TLS being a special section means, that only POD can be stored there, since there is no place where TLS complex data could be initialized or finalized. — Preceding unsigned comment added by 81.210.82.34 (talk) 08:37, 12 July 2012 (UTC)

Implementation vs API
The implementation sections seem not to be about implementation but about API's; the actual implementations are not described, just some API function names listed. -- Hkultala (talk) 09:00, 30 August 2010 (UTC)

Merger proposal
I think Thread-Specific Storage should be merged into Thread-local storage. Google shows 6,960 for "thread specific storage" and 76,700 for "thread local storage". b4hand (talk) 01:06, 27 February 2008 (UTC)
 * That other article doesn't contain much new material; I think the only thing worth carrying over to here is the name, if we can find a good reference for it. Shinobu (talk) 08:06, 21 April 2008 (UTC)
 * Agreed, done. —Jorend (talk) 17:59, 3 June 2008 (UTC)

Huh?
This sentence makes no sense at all:

> TLS with POSIX Threads, thread-specific data in Pthreads nomenclature, is similar to TlsAlloc and related functionality for Windows.

Posix thread local storage is similar to a Windoze function? What does that mean? — Preceding unsigned comment added by 195.212.29.186 (talk) 06:42, 8 May 2013 (UTC)
 * that mean, you have got a butthurt. That always happens when some PUSSYX/Crapux/Clinix zealot reads out that something in his PUSSYX/Crapux/Clinix is *LIKE* in Windows. Then the butthurt comes to him. Right. Remove all the PUSSYX/Crapux/Clinix things from there, because Tls is really the Windows thing, since only there threads are the real threads, and in the PUSSYX/Crapux/Clinix world even now one can not distinct properly between a process and a thread, and doesn't understand what a thread is at all.

77.52.154.175 (talk) 22:19, 29 August 2013 (UTC)


 * I just added a real description of pthread thread-specific storage. That sentence was no longer necessary so it's gone. Martinkunev (talk) 11:00, 21 August 2015 (UTC)

Processor Support & General Aspects
Certain types of modern processors (e.g. many models of Intel x86 architecture) do come with hardware support for such a functionality. In general the most used processor design base comes with local stacks and with local registers that are definitely serving identical needs: a single thread has its very own private set of resources (where some of it can be published to others and some can not). actual multitasking methods & systems do take care of that by saving stack pointers and local register states when making a thread wait, and they will restore those values when making a certain thread again running. rationale: TLS is the long term memory variant for thread local data whilst stack and registers are the short to very short term storage for thread local data. --Alexander.stohr (talk) 14:19, 15 April 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 external links on Thread-local storage. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20090422193747/http://www.dre.vanderbilt.edu/Doxygen/Stable/ace/classACE__TSS.html to http://www.dre.vanderbilt.edu/Doxygen/Stable/ace/classACE__TSS.html
 * Added archive https://web.archive.org/web/20090425235842/http://www2.roguewave.com/support/docs/hppdocs/thrref/rwtthreadlocal.html to http://www.roguewave.com/support/docs/hppdocs/thrref/rwtthreadlocal.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 15:47, 30 December 2017 (UTC)

Maybe maybe NOT
Win10 is top mention on TLS? no.

I MUST INTERJECT. Win10 should be mentioned last not first for thread programming or parallel both: they are LATE in the game. This function mentioned above is vicarious, new, and may change. Also: it was taken from Unix, it is NOT from Microsoft. Also: paging is a matter of task switching and security done by the CPU and kerne:  it is tot. unrelated to TLS, which purports itself as a kind of CPU kernel task switching hardware extension embedded in (libc) by ASM macros (as to if that what is TLS is I do not discuss).

mp, mpfr, mpc allow gcc to access multiple processors. the Kernel has code supported thread switching - which gradually gets replaces by any new Intel functions offered to accelerate task switchign (WHICH INCULDES allowing tasks to mark share or unshare memory pages: libc shouldn't even be allowed access to these !!)

TLS "copies certain parts of my apps memory per thread". question is why can't my app do that is my app poorly designed? Is it hardware accelerated or just a "versional, must upgrade" wrapper feature of OS libs? who is allowed to copy what memory.

I end by saying: it's a known fact parts of pthread in LIBC specifically site they DO NOT GET UID GID while doing thread work "but should"

what is TLS, really