Monthly Archives: February 2006

Storing thread local using Thread Local Storage (TLS)

Have you ever needed to store data locally to a thread ? For example, let’s say that you want to implement a GetLastErrorMsg() function. This function would complement the standard GetLastError() one by providing a string description of the last error.

How would you implement it ? You need to store the error description on a per thread basis. Will you use a map whose key would be the thread ID and data the error message ? Since you don’t know when threads terminate, when will you delete entries of the map ? What happens if a thread terminates and a new one starts with the same thread ID ? This is definitely not a good approach !

A nicer and easier solution is to use the __declspec( thread ) directive (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_the_thread_attribute.asp).

This directive allows you to specify that a global or member variable is local to a thread. Each time you will use the variable, it will the one specific to the thread, and will be deallocated once it is terminated.

The following code illustrates the use of this directive for the implementation of the GetLastErrorMsg() function.

The thread local storage can be used dynamically too, using the TlsAlloc(), LocalAlloc(), TlsSetValue() and TlsGetValue() functions. This is useful when working with DLL to store Data when threads attach to and detach from the DLL. See the MSDN article about this : “Using Thread Local Storage in a Dynamic-Link Library” (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/using_thread_local_storage_in_a_dynamic_link_library.asp)

#include "stdafx.h"
#include "myError.h"
using namespace std;

__declspec( thread ) char g_szMsg[256] = "";

 const char* GetMyLastErrorMsg() { return g_szMsg; }

void SetMyLastErrorMsg( const char* szMsg) {
    strcpy( g_szMsg, szMsg); 
}

UINT MyThread( LPVOID pParam )
{
    int iDelay = (int)pParam;
    char szMsg[ 256 ];
    sprintf( szMsg, "Thread %d Message %d", GetCurrentThreadId(), iDelay );
    SetMyLastErrorMsg( szMsg );
    cout << "Set " << szMsg << endl;
    Sleep( iDelay );
    cout << "Get " << GetMyLastErrorMsg() << endl;
    return 0;
} // UINT MyThread

int main(int argc, char* argv[])
{
    CWinThread* pThread = NULL;
    for ( int i = 1; i <= 10; i++ )
    {
        pThread = AfxBeginThread( MyThread, (LPVOID)(i * 1000) );
    }

    WaitForSingleObject( pThread->m_hThread, INFINITE );
    return 0;
}

C++ IMAP client component

I needed to replace the Easymail IMAP client component that my company uses because it doesn’t support imbricated forwarded attachment ( an attachment which is a mail containing an attachment which is mail containing an attachment which is a mail, …)

I found different IMAP clients :

  1. The one which looked better a first was the n-software Ip*Works solution (www.nsoftware.com). This IMAP component is really well designed and support imbricated attachments. However, it appeared that it is not thread safe. Calling a method of the IMAP class from a thread different from the one in which the class was instanciated causes strange behaviour ( slow answer from the server). The n-software support confirmed it’s a known issue, and that it cannot be fixed. What a pity 🙁
  2. I tried the Chilkat IMAP component (www.chilkatsoft.com/). It was presented as thread safe, and stress tested in ASP farms. Although the component is not really well designed, I tried it. But it appeared that it didn’t work with all the IMAP servers I tried (especially the Vircom Modus one), and in some cases it throws exception (access violation)  when the documentation said it shouldn’t. Moreover, in the very simple demo application I wrote. I had memory leaks even when only doing a login logout… I may have been unlucky with my tests, but I will avoid this component.
  3. Finally, I tested a IMAP client from Hunny Soft (http://www.hunnysoft.com/mailpp/index.htm). First, I noticed that it was possible to purchase the source code of this component. And finally, this is the BIG WINNER ! It really is well designed, easy to use, efficient. It looks like it can be used in a multi thread context without problems. That’s the one I will recommend !