The Practical Guide to Multithreading – Part 1

Managing Threads

Following table lists out common operations with threads and how you achieve them using different programming elements. This list does not include communicating with thread while it is running, nor it lists thread-security, thread-priority etc. POSIX threads are not used in this article, but listed here for completeness.

Adding in favor of Graceful ending threads: It is always recommended to let the thread function (the root function of thread, like ‘main’ function for the process) return and end the thread properly. Calling the respective functions (as listed) for End-Thread-Gracefully has some issues. Few of them could be: Open file may not be closed, C++ class-objects would not be destroyed via destructor, thread-synchronization object would be inconsistent (later on this), and other issues.

I assume basic understanding of threads from the reader, but I still mention few points:

Okay! Here is the code to create threads. The simplest approaches are chosen.

MFC:

UINT Example1Thread(void*);

void CExample1_Dlg::OnBnClickedOk()
{
	AfxBeginThread(Example1Thread, this);

	// OnOK();
}

UINT Example1Thread(void *pParam)
{
	CExample1_Dlg* pThis= (CCExample1_Dlg*)pParam;

	// Use pThis
	// Perform processing

	return 0;
}

Please note the syntax of ‘Example1Thread’. AfxBeginThread requires the function-pointer, which returns ‘UINT’ and takes ‘void*’. The void* argument content is same what we pass as second argument to AfxBeginThread. Since we know the exact type, we further typecast it to C++ class type.

Is must be noted that AfxBeginThread/CreateThread requests the Operating System to create the thread and eventually run it. Thread creation function does not wait the thread-routine to finish (Otherwise there is no meaning of multithreading!)

C# / .NET:

// using System.Threading;
private void btnStartThreaded_Click(object sender, EventArgs e)
{
    Thread MyThread = new Thread(ProcessRoutine);
    MyThread.Start();
}
void ProcessRoutine()
{
    // Do processing here.
    // We better make this method 'static'
    // But we'll take those things later.
    // Here we can use all member of class directly (since we have 'this')
}

Fine! We now put the code in ‘ProcessRoutine’ which was in ‘btnProcess_Click’ (see first code above). When we run (with F5), Visual Studio launches new world for us! It interrupts the debugging session, and shows Cross Thread Access exception:

If you run it without debugging (i.e. using Ctrl+F5), the program would run and would work as expected. But the program may crash down at any time. The similar thing would happen for MFC based application. The debugger may show some assert at some remote location, showing some alien code of MFC library. Remember that MFC window classes are not thread safe.

Why does it happen?

You know that you cannot open the same file in write-mode simultaneously, and change it contents (ignore advanced ways to do that, if you know!). Files, windows, sockets, data-buffers, screens (and other devices), database tables etc. are some kind of Objects. These objects, mostly, prevent simultaneous modification to them. The reason is simple: Consistency!
In general, you perform modification to objects in following pattern:

1. Wait for the object to become free for modification
2. Open object to modify
3. Modify the contents of object
4. Close the object, so that others can open it.

You may list some type of objects (like database tables), that allows simultaneous modification. Well, they internally use multithreading concepts, which you would get to know soon!

What it has to do with the current problem in hand

The windows (or say controls) are created by some thread, generally by primary thread of application, but that is not necessary. That thread holds the ‘write’ access to modify the contents. We are trying to modify the contents using other thread, which violates the rule of ‘consistency’ we discussed previously. We also cannot use 4-step process (wait, open, modify, close) to amend the contents of window (object). Closing the window object would literally mean destroying the window (control).
Please note that modifying window-object does not mean changing the text/caption only, but includes modifying any of its properties (like color, shading, font, size, orientation, visibility etc) also.

So, what can be done?

We can send or post a message to the window! If you can recall correctly Sending the message (via SendMessage/Invoke) is synchronous operation. It means you notify a window, and wait the target window to finish the operation. For example you can send WM_SETTEXT message from other window to set the text of target window. Don’t get confused over this weird name (WM_SETTEXT) or on the actual usage of SendMessage. Things will come out of blur, as we move on! Calling SendMessage this way is same as calling SetWindowText (see code).

UINT Example1Thread(void *pParam)
{
	CExample1_Dlg* pThis= (CExample1_Dlg*)pParam;

	pThis->SendMessage(WM_SETTEXT, 0,(LPARAM)L"New Caption!");

	// eq. to ::SendMessage(pThis->m_hWnd, WM_SETTEXT, 0,(LPARAM)L"New Caption!");

        // pThis->SetWindowText("New Caption!");
        // SetWindowText internally calls SendMessage, which sends WM_SETTEXT message to target window.

	return 0;
}

Calling SendMessage from any thread to any window is safe! But it’s not true with MFC objects, and not with .NET control classes. Be aware. They represent complex class-objects, and are not simple handles. Okay, I won’t elaborate more about this here, but would continue to our multithreading session. 🙂

Continuing with the problem…
Now let us update the progress bar and status-text in properly threaded manner:

// Delegates - same as function pointers.
// First line declares type, second declares variable
delegate void DelegateType(int x);
DelegateType TheDelegate;

// We store the Start and End values in class-variable, so that 'thread' actually does only processing.
int StartFrom, EndTo;
private void btnStartThreaded_Click(object sender, EventArgs e)
{
    // Set the delegate.
    TheDelegate = MessageHandler;

    StartFrom = Convert.ToInt32(txtStart.Text);
    EndTo = Convert.ToInt32(txtEnd.Text);

    prgProcess.Minimum = StartFrom;
    prgProcess.Maximum = EndTo;

    // Disable button, so that user cannot start again.
    btnStartThreaded.Enabled = false;

    // Setup thread and start!
    Thread MyThread = new Thread(ProcessRoutine);
    MyThread.Start();
}

// This is delegated function, runs in the primary-thread (i.e. the thread that owns the Form!)
void MessageHandler(int nProgress)
{
    lblStatus.Text = "Processing item: " + Convert.ToString(nProgress);
    prgProcess.Value = nProgress;
}

void ProcessRoutine()
{
    for (int nValue = StartFrom; nValue <= EndTo; nValue++)
    {
        // Only actual delegates be called with Invoke, and not functions!
        this.Invoke(this.TheDelegate, nValue);
    }
}

I request you to study about delegates. In short, delegates are like function-pointers in C/C++. You set some delegate-variable to appropriate type of function. Further you call Invoke or BeginInvoke, that would eventually call the function in the context of thread to which the control belongs. Remember all controls (forms, comboboxes, progress bars etc) are derived from System.Control).
In the sample above, I have disabled the button so that user cannot start processing again.

The MFC approach:

UINT Example1Thread(void*);

void CExample1_Dlg::OnBnClickedOk()
{
	// Get start and end values
	StartFrom = GetDlgItemInt(IDC_START);
	EndTo = GetDlgItemInt(IDC_END);

	// Set progress bar range
	ProgressBar.SetRange(StartFrom, EndTo);

	// Disable button
	GetDlgItem(IDOK)->EnableWindow(FALSE);

	// Start off the thread
	AfxBeginThread(Example1Thread, this);
}

// The thread message handler (WM_MY_THREAD_MESSAGE)
// -- #define WM_MY_THREAD_MESSAGE	WM_APP+100
// -- ON_MESSAGE(WM_MY_THREAD_MESSAGE, OnThreadMessage)
LRESULT CExample1_Dlg::OnThreadMessage(WPARAM wParam, LPARAM)
{
	int nProgress= (int)wParam;

	// update progress bar
	ProgressBar.SetPos(nProgress);

	CString strStatus;
	strStatus.Format("Processing item: %d", nProgress);

	// update status text
	StatusText.SetWindowText(strStatus);

	return 0;
}


UINT Example1Thread(void *pParam)
{
	CExample1_Dlg* pThis= (CExample1_Dlg*)pParam;

	for (int nValue = pThis->StartFrom; nValue <= pThis->EndTo;  ++nValue)
		pThis->SendMessage(WM_MY_THREAD_MESSAGE, nValue);

	return 0;
}

The thread is calling SendMessage with WM_MY_THREAD_MESSAGE message (custom message). This, in turn, calls OnThreadMessage in the primary thread's context, and thus updating controls is thread-safe!

(For MFC/WinAPI programmers: Though this example may be starting point for you to understand and use SendMessage, ON_MESSAGE and defining/handling user-messages; and you might find it easy. I request you to read some material, try some stuff yourself!)

Here it looks like:

The last note before we move on to two more practical examples. The approach chosen here (in both C++ and C#) is not appropriate.

Now move on to next page where we would handle these four issues, along with allowing user to Cancel (practical example 2), and allowing user to Pause/Resume too (example 3)!