This page was last modified 17:29, 1 July 2008.
How to use Thread Local Storage
From Forum Nokia Wiki
DLL can manage writable static data on a per-thread basis using thread-local storage, commonly known as ”TLS”. This allocates a single machine word of writable static data per thread for every DLL, regardless of whether the DLL uses it. Obviously, the memory overhead is far less significant than allocating a 4 KB chunk for each DLL which uses static data. However, the price of using TLS instead of Direct Memory Access is performance; data is retrieved from TLS about 30 times slower than direct access, because the lookup involves a context switch to the kernel in order to access the data.
Thread-local storage is usually initialized when the DLL is attached to a thread within the DLL entry point, E32Dll().Typically, code is added to construct the struct containing the global data and store it in thread-local storage using the static function Dll::SetTLS().To access the data, you should use the static function Dll::Tls(). This will return a TAny* which can be cast and used to access the data. For simplicity, you may wish to provide a utility function, or set of functions, to access the data from a single point.
TLS is thread and DLL -specific so every DLL in a thread can use it without risk of mixups.
Usage example
// Create an object and store the pointer in TLS CSomeClass* object = CSomeClass::NewL(); User::LeaveIfError( Dll::SetTls( object ) ); // Get the object from TLS object = static_cast<CSomeClass*>( Dll::Tls() ); // When done with the object, delete it and free TLS delete object; object = NULL; Dll::FreeTls();Note! The TLS does not take ownership of the object so the user is responsible for deleting it.
Usage example in an EXE project
The above code uses the static Dll class to access the TLS which means it only works in a DLL project. TLS can also be used in an EXE project, but through a different static class. UserSvr provides the same API to TLS except that it requires somekind of an id to the pointer being stored. The Dll class actually uses UserSvr to access TLS provinding the DLL module handle as the id. The same code example in an EXE project would look something like this:
#include <e32svr.h> // For UserSvr // Define a handle. This has to be unique within the thread. const TInt KMyTlsHandle = 0xC0FFEE; // Create an object and store the pointer in TLS CSomeObject* object = CSomeObject::NewL(); User::LeaveIfError( UserSvr::DllSetTls( KMyTlsHandle, object ) ); // Get the object from TLS object = static_cast<CSomeObject*>( UserSvr::DllTls( KMyTlsHandle ) ); // When done with the object, delete it and free TLS delete object; object = NULL; UserSvr::DllFreeTls( KMyTlsHandle );
| Related Discussions | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Slow when installing on mass storage / N95 | Lacronec | Mobile Java General | 3 | 2008-05-30 14:03 |
| SMS storage in SIM | yanamas | News, Announcements and Job Listings | 4 | 2008-04-15 13:06 |
| RMS available size | nwk1981 | Mobile Java General | 1 | 2004-05-13 07:51 |
| Thread parameter problem | Allen3 | General Symbian C++ | 13 | 2007-02-21 03:28 |
| Persistent form storage | bhavish | General Symbian C++ | 1 | 2006-12-25 06:32 |
