The use of TLS

[reverse]

I have a question about TLS.
I put below code into both EXE and DLL

#define TLS __declspec(thread)
TLS int a;

In multithread, the EXE program is working well.
But DLL program attached to multithreading program such as IIS isn't working.
In In-Process COM, also is not working.

I want to use TLS in COM. But I'm not convinced that this is realizable.

Is it OK if I believe TLS will be well working in COM?

A programmer who loves Goethe.

I know that we should not use TLS in COM as COM calls do not have any thread-affinity. In other words, calls to the same object need not arrive on the same thread(s).

[thomas_mathews]

hello,

Do any one know more about why the dll crashes when TLS is used.I used in one simple dll the TLS it works fine.
If any one knows more about TLS and dll please post reply. One thing i noted that when i use TLS(Thread local storage) the is entry in .tls section but no entry in TlsTable in Data Directory why? is only with borland or any other complier it creates the entry in TlsTable in Data Directory ???

Regards,
Thomas

[rxbagain]

If we look at the documentation of __declspec(thread), we can find this, "The use of __declspec(thread) may interfere with delay loading of DLL imports." and regarding the constraint MSDN says this

Delay loading of a DLL may not result in the same behavior of the process if there are per-process initializations that occur in the entry point of the delay-loaded DLL. Other cases include static TLS (thread local storage, declared using __declspec(thread) which is not handled when the DLL is loaded via LoadLibrary. Dynamic TLS, using TlsAlloc,TlsFree,TlsGetValue,TlsSetValue is still available for use in either static or delay-loaded DLLs.

This is the reason why statically linking a dll will work fine, but using it in COM or other methods that uses Loadlibrary will fail.

Hope it will clarify your concern