Delphi DLL - thread safe

Question

I have a Delphi DLL and I want to load it in my app inside a thread (more than one, to be exactly). The DLL just creates a object, then it uses it and destroys it. For that

Answer 1

If you are careful about what you do in the thread, you'll be ok. If you need to update the VCL of the main thread, use synchronize, or better yet, don't.

I have a big DLL where I do lots of database access, and it runs in a thread. Everything worked great in my unit tests, but blew up sky high when run within a thread in the main app. Turns out, I had to re-read the database docs on thread safety. In my case, it's DBISAM and I just had to be sure to create a new session for the threaded database instance, so it wouldn't collide with the main one.

Another place where I ran into trouble (again, worked great in unit tests, failed in threads) is with XML handling. I had to call CoInitialize/CoUnInitialize before/after using the XML DOM stuff. This holds true for any SOAP stuff, which uses the XML DOM under the hood.

Answer 2

Set IsMultiThread to True the first thing in the main block of your library project:

library MyLibrary;
begin
  IsMultiThread := True;
  ...
end.

This will instruct the memory manager to use thread-safe allocation/deallocation routines.

Answer 3

The most common pitfall is use of global variables. So long as you don't use any global variables (or properly synchronise access to the ones you do use) you will be a long way towards thread safety.

IsMultiThread is used by, for example, the memory manager to make optimisations in the single threaded case. Personally I don't feel this is a worthwhile optimisation these days since practically all useful code has threads of some description. I'd just set IsMultiThread to True at the start of your DLL, e.g. in the begin/end block of your DLL .dpr file, or in one of your unit's initialization sections which amounts to the same thing.

To answer your question directly, the instance of IsMultiThread in your DLL will not be set true unless you create a thread in that DLL. Since you create the threads in your EXE you need to do it yourself in the DLL.

More generally, it's simply impossible to say much about thread safety of your code without knowing what it does and what you actually mean by thread safe. The latter point may sound odd, but what I'm referring to is the issue discussed in Eric Lippert's famous What is this thing you call "thread safe"? article.