digitalmars.D.announce - Thread Local Storage Template
- Mikola Lysenko (10/10) Sep 11 2006 The current version of D does not have thread local storage. This is a
- Stewart Gordon (12/24) Sep 12 2006 What exactly can this do that cannot be done by simply deriving a class
- xs0 (4/20) Sep 12 2006 afaik, nothing, but that's not always an option; almost any kind of
- Sean Kelly (3/19) Sep 12 2006 Provide thread-local storage for the main thread.
- Stewart Gordon (21/33) Sep 12 2006 I figured out what it was doing after a while. So it provides access to...
- Mikola Lysenko (24/34) Sep 12 2006 There are plenty of uses for thread local storage. Particularly if you
The current version of D does not have thread local storage. This is a very useful feature, and the lack of support is frustrating. The problem is compounded by the fact that there are no truly cross platform thread local storage facilities. To work around this problem, I have created a simple templatized wrapper. It currently supports DMD and GDC on the following platforms: Windows Linux Mac OS X You can download it at: http://www.assertfalse.com/projects.shtml
Sep 11 2006
Mikola Lysenko wrote:The current version of D does not have thread local storage. This is a very useful feature, and the lack of support is frustrating. The problem is compounded by the fact that there are no truly cross platform thread local storage facilities. To work around this problem, I have created a simple templatized wrapper. It currently supports DMD and GDC on the following platforms: Windows Linux Mac OS X You can download it at: http://www.assertfalse.com/projects.shtmlWhat exactly can this do that cannot be done by simply deriving a class from Thread and adding member variables? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 12 2006
Stewart Gordon wrote:Mikola Lysenko wrote:afaik, nothing, but that's not always an option; almost any kind of library can hardly require that you use a specific Thread type.. xs0The current version of D does not have thread local storage. This is a very useful feature, and the lack of support is frustrating. The problem is compounded by the fact that there are no truly cross platform thread local storage facilities. To work around this problem, I have created a simple templatized wrapper. It currently supports DMD and GDC on the following platforms: Windows Linux Mac OS X You can download it at: http://www.assertfalse.com/projects.shtmlWhat exactly can this do that cannot be done by simply deriving a class from Thread and adding member variables?
Sep 12 2006
Stewart Gordon wrote:Mikola Lysenko wrote:Provide thread-local storage for the main thread. SeanThe current version of D does not have thread local storage. This is a very useful feature, and the lack of support is frustrating. The problem is compounded by the fact that there are no truly cross platform thread local storage facilities. To work around this problem, I have created a simple templatized wrapper. It currently supports DMD and GDC on the following platforms: Windows Linux Mac OS X You can download it at: http://www.assertfalse.com/projects.shtmlWhat exactly can this do that cannot be done by simply deriving a class from Thread and adding member variables?
Sep 12 2006
Mikola Lysenko wrote:The current version of D does not have thread local storage. This is a very useful feature, and the lack of support is frustrating. The problem is compounded by the fact that there are no truly cross platform thread local storage facilities. To work around this problem, I have created a simple templatized wrapper. It currently supports DMD and GDC on the following platforms: Windows Linux Mac OS X You can download it at: http://www.assertfalse.com/projects.shtmlI figured out what it was doing after a while. So it provides access to a per-thread data store that only the associated thread can access, without having to go through a Thread object to get to it. At first I thought that tls_key was some per-thread key, but then I realised it's a key related to the ThreadLocal object. So you can use more than one ThreadLocal at the same time. I can see that this idea in itself might have some practical uses, I'm just trying to think what they are.... Is there a particular reason that the whole code is duplicated between TLS_UsePthreads and TLS_UseWinAPI, rather than versioning only what's different? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 12 2006
Stewart Gordon wrote:I can see that this idea in itself might have some practical uses, I'm just trying to think what they are.... Is there a particular reason that the whole code is duplicated between TLS_UsePthreads and TLS_UseWinAPI, rather than versioning only what's different? Stewart.There are plenty of uses for thread local storage. Particularly if you want to have some sort of static variable that must be unique to each thread without modifying the code for the thread object. For example, StackThreads has a static getRunning method that returns the currently executing context. Each thread may be executing a different context, so there needs to be some mechanism for directly associating each context with each thread. Adding a member to each thread is not only impractical, but also illegal. You could avoid using getRunning by passing the running context around as a parameter, but this becomes very confusing very quickly. Thread local storage simplifies things. By placing the current context in thread local storage, it is trivial to determine which context is currently executing in a given thread. Here are some other examples: http://plonetest.haiku-os.org/node/53 http://www.c-sharpcorner.com/Code/2003/March/UseThreadLocals.asp Besides the places where it simplifies design, several algorithms can benefit by reducing synchronization costs with technique. There are many well known memory allocators that require a separate pool for each thread. By avoiding the overhead of acquiring a common lock, the level of contention is reduced and overall system throughput is increased. As for where to place the version statements, this is a purely aesthetic choice. In support of the style, std.thread does things the same way.
Sep 12 2006