This blog has moved. Please update your bookmarks.

Threads are HARD

I'm up in Northern Sweden right now at a customer site and debugging our application.

When we released the 2.0 version, some thought that the program was much slower than before. The main reason as to why is that the program was previously split apart into two programs, communicating through Windows messages. Now they're all integrated into one application, which means there's only one thread that does everything. So nothing happens in parallell anymore, and this means that people have to wait for operations to finish before continuing.

Enter threads.

The main problem with threads is that the execution takes places in parallell, but within a fundamentally single-threaded framework (VCL). So worker threads are created, but need to synchronize with the main application when they're done. Furthermore, some requests must wait for the worker threads to complete before they can continue.

And most importantly: any reference - any single one - to a VCL object in a thread can cause the application to throw an exception. Or crash wildly.

Culprits so far: Forgetting to embed everything in try/except blocks in TThread's; using Create( Self ) on objects which run in multiple threads (must use nil instead of Self) and spurious Application.ProcessMessages that cause threads to interject update calls in potentially sensitive areas of code in the main thread.

All this makes me wonder how stable things are going to be when we eventually end up with four or eight processors in workstations. Servers are easier because they typically don't require access to screen elements and message loops. But end-user UI programs... that's hard.


Post a Comment

<< Home


Blog contents copyright © 2005 Mats Gefvert. All rights reserved.