trying to understand DLL and Thread local storage
-
Just realized posted to wrong forum however the variable is in static or global storage the next thread that comes by can change its value thats my problem just about all the. examples for TLS and DLL s have it this way
ForNow wrote:
the next thread that comes by can change its value
Well yes, if you do it wrong you can shoot yourself in the foot. As far as I can see, the example you're looking at is not doing it wrong. The global variable is initialized once, in the place where the documentation says it should be initialized. This seems to be a case of "if I stick a fork in my toaster whilst it's switched on, I can get an electric shock; therefore, all toasters are dangerous and should be banned". :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Hi I have been looking at the examples off dll and TLS First thing I noticed that
DWORD g_dwThreadIndex;
is in global storage It would be nice as in the IBM manuals would have registers on at entry to DllMain I mean is the SP (register) that of the calling application regardless if the index returned from tlsalloc lets say is 5 and then before the current thread access the storage set by tlssetvalue another thread does a tlsallloc g_dwThreadindex becomes 6 then the first thread then does tlsgetvalue it would be using 6 instead of 5 obviously I am not understanding something I mean if gw_dwThreadindex would be defined in the callers stack I would get it more so is the anyway of knowing the identity of the caller I mean maybe process id or thread guess I could do a call to Startupinfo
The actual source of the code referenced Using Thread Local Storage in a Dynamic-Link Library - Win32 apps | Microsoft Learn[^] Following is also relevant to see the messages. DllMain entry point (Process.h) - Win32 apps | Microsoft Learn[^] The code example is skipping the normal TLS semantics. So in other words it is using the first TLS index for all storage. Within the code provided. This might follow into the following comment...
ForNow wrote:
and then before the current thread access the storage set by tlssetvalue another thread does a tlsallloc g_dwThreadindex becomes 6
Not exactly sure what you are saying there but I think you are presuming that somehow this initialization code is not thread safe. In that it might be called by multiple threads at the same time. This code method will never be called by more than one thread at a time. Additionally the 'DLL_PROCESS_ATTACH' will never be called more than once (within one process space of course.)
-
I'm not sure I quite understand what you are asking, but each thread gets its own stack (pointed at by SP) which provides all the thread local storage. It can also allocate its own storage through the normal methods. You have not really explained what
g_dwThreadIndexis being used for in relation to the question. Does this all relate to some article, or specific MSDN page?Richard I think I’m begging to understand the source of my confusion First it is my understanding there are Two types off DLL one for the entire operating system in my case windows 10 and one servicing threads of one address space if it’s the former I mean that works like USER.DLL then the code example of tls wouldn’t work an I right in this ?
-
The actual source of the code referenced Using Thread Local Storage in a Dynamic-Link Library - Win32 apps | Microsoft Learn[^] Following is also relevant to see the messages. DllMain entry point (Process.h) - Win32 apps | Microsoft Learn[^] The code example is skipping the normal TLS semantics. So in other words it is using the first TLS index for all storage. Within the code provided. This might follow into the following comment...
ForNow wrote:
and then before the current thread access the storage set by tlssetvalue another thread does a tlsallloc g_dwThreadindex becomes 6
Not exactly sure what you are saying there but I think you are presuming that somehow this initialization code is not thread safe. In that it might be called by multiple threads at the same time. This code method will never be called by more than one thread at a time. Additionally the 'DLL_PROCESS_ATTACH' will never be called more than once (within one process space of course.)
Hi I think I’m begging to understand the source of my confusion It is my understanding there are two types of dll’s One services the entire os like kerenel.DLL and one just a particular address space if my code is of the former than this example is not PROCESS safe am I correct in my understanding ?
-
ForNow wrote:
the next thread that comes by can change its value
Well yes, if you do it wrong you can shoot yourself in the foot. As far as I can see, the example you're looking at is not doing it wrong. The global variable is initialized once, in the place where the documentation says it should be initialized. This seems to be a case of "if I stick a fork in my toaster whilst it's switched on, I can get an electric shock; therefore, all toasters are dangerous and should be banned". :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Richard I think I’m begging to understand the source of my confusion First it is my understanding there are Two types off DLL one for the entire operating system in my case windows 10 and one servicing threads of one address space if it’s the former I mean that works like USER.DLL then the code example of tls wouldn’t work an I right in this ?
No there is only one type of DLL, which is a Dynamically Loadable Library. However, it may, or may not, be thread safe, depending on how it is created. Most (all?) of the Windows provided DLLs are thread safe. And the whole point of having DLLs is that the system only needs to load it once, to service multiple executables (i.e. address spaces). Be that as it may, I am still not sure what your concern is with regard to threads.
-
No there is only one type of DLL, which is a Dynamically Loadable Library. However, it may, or may not, be thread safe, depending on how it is created. Most (all?) of the Windows provided DLLs are thread safe. And the whole point of having DLLs is that the system only needs to load it once, to service multiple executables (i.e. address spaces). Be that as it may, I am still not sure what your concern is with regard to threads.
-
Hi I think I’m begging to understand the source of my confusion It is my understanding there are two types of dll’s One services the entire os like kerenel.DLL and one just a particular address space if my code is of the former than this example is not PROCESS safe am I correct in my understanding ?
ForNow wrote:
there are two types of dll’s
Sort of true but also not true. When a dll is loaded the whatever loaded it decides how to use it. In one case the defining characteristic of an 'application' is that it must have a defined entry point and other defined behaviors. That is true for every operating system (not just windows and dlls.) The code above provides a defined entry point. Other dlls might just be libraries and they might have many 'entry' points (methods) although how each of those is defined (laid out in the dll) defines whether it can be successfully called and even how it must be called. All of that is rather esoteric though and is almost never going to be an issue.
-
Hi I have been looking at the examples off dll and TLS First thing I noticed that
DWORD g_dwThreadIndex;
is in global storage It would be nice as in the IBM manuals would have registers on at entry to DllMain I mean is the SP (register) that of the calling application regardless if the index returned from tlsalloc lets say is 5 and then before the current thread access the storage set by tlssetvalue another thread does a tlsallloc g_dwThreadindex becomes 6 then the first thread then does tlsgetvalue it would be using 6 instead of 5 obviously I am not understanding something I mean if gw_dwThreadindex would be defined in the callers stack I would get it more so is the anyway of knowing the identity of the caller I mean maybe process id or thread guess I could do a call to Startupinfo
-
Hi I have been looking at the examples off dll and TLS First thing I noticed that
DWORD g_dwThreadIndex;
is in global storage It would be nice as in the IBM manuals would have registers on at entry to DllMain I mean is the SP (register) that of the calling application regardless if the index returned from tlsalloc lets say is 5 and then before the current thread access the storage set by tlssetvalue another thread does a tlsallloc g_dwThreadindex becomes 6 then the first thread then does tlsgetvalue it would be using 6 instead of 5 obviously I am not understanding something I mean if gw_dwThreadindex would be defined in the callers stack I would get it more so is the anyway of knowing the identity of the caller I mean maybe process id or thread guess I could do a call to Startupinfo
