Oldest known version of this page was edited on 2007-09-26 09:15:01 by AndreasSedlmeier [added some considerations regarding thread-safety and "legacy DLLs"]

usage of "Legacy DLLs" with eDeveloper v9 and 10

There's some "legacy DLLs" available and widely used with Magic eDeveloper which were originally designed for v7 and 8 which are not thread-safe.
This became an issue when Magic itself became "multi-threaded" (which is the case for v9/10 multi-threaded background application servers and v10 parallel execution tasks)

A DLL (function) which is not thread-safe you basically cannot use in a multi-threaded situation/environment, the results are unpredictable. While it might work just fine for a while it (and this gets more likely if you call functions within that DLL frequently) might also simply crash Magic/eDeveloper (and that would be still even better than getting completely unpredictable, wrong, results - which is something which might happen too).

If a DLL is thread-safe or not is basically something you need to ask ask the author/vendor about or - if there's - lookup that information in the accompanying documentation.

GetDll for example is one of these "legacy DLLs" which is known to be not thread-safe and this is a pity because it contains a whole bunch of functions which are (still) not available in Magic and which you might want to use.

The good news is ... much of the actually not thread-safe functions in these DLLs you can "render" thread safe by means of external synchronization. You simply ensure that there'll be never two threads running in parallel which access a particular function at the same time.

One "synchronization object" eDeveloper offers to achieve this are f.i. the lock functions Lock() and Unlock(). Database locks you could use as well.
If you "wrap" the invocation of a function within a DLL within a synchronization block you can ensure that there'll be never two threads (tasks) which try to invoke this function at the same time. The first one will get the lock, the next one will have to wait until the first one is finished.

"Pseudo Magic-code" which tries to get file modification date/time with get.dll for a file c:\test.txt could look like this:

Try to keep things you do within that synchronization block as short as possible.

Note: DLL functions which you can render thread safe like described above by external synchronization are sometimes referred to as "Thread compatible" (at least by Java programmers). There's however things which you cannot get thread-safe - whatever you try and these things are then sometimes referred to as "Thread hostile" (by the same guys). Fortunately these latter cases are relatively rare. A simple function like the one used in the sample (get.get_io_date) almost certainly is not - without access to the source its however not possible to tell.

Some things get.dll does are likely to be thread-hostile. They certainly require to maintain some state over longer time. Concurrent use will mess that up.

Usage of external DLLs
Characterizing thread safety (Java theory and practice)∞