www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Thread Local Storage Template

reply Mikola Lysenko <mclysenk mtu.edu> writes:
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
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.shtml
What 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
next sibling parent xs0 <xs0 xs0.com> writes:
Stewart Gordon wrote:
 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.shtml
What exactly can this do that cannot be done by simply deriving a class from Thread and adding member variables?
afaik, nothing, but that's not always an option; almost any kind of library can hardly require that you use a specific Thread type.. xs0
Sep 12 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Stewart Gordon wrote:
 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.shtml
What exactly can this do that cannot be done by simply deriving a class from Thread and adding member variables?
Provide thread-local storage for the main thread. Sean
Sep 12 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.shtml
I 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
parent Mikola Lysenko <mclysenk mtu.edu> writes:
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