My understanding is that DLLs are reentrant. That's sort of the idea behind a DLL in the first place. The thread that makes a call into the DLL has its own stack, and since data is not shared between thread stacks, each call has its own data area. However, if you have, for example, a memory mapped file, a named pipe, a resource handle to say a GDI brush, then you have a resource that's shared by the OS across threads. This has nothing to do with the DLL, but accessing that resource inside of the DLL can cause threading issues to arise, since the various callers of the DLL run asynchronously. For example, suppose your DLL retrieves a handle to brush or writes, reads, then deletes the contents of a memory mapped file. One thread calls into the DLL and, before it exits, is swapped out by the task manager. That thread's stack is set aside and its place of execution within the DLL is marked, then the new thread begins execution. Say the first thread wrote data to the file, but did not read or delete its data. The new thread comes in and writes its data, but when it reads the data back, it gets its data and the data from the previous thread. Then the second thread deletes its data and the data placed there from the previous thread. When the original thread is swapped back in, there is no data there to read back anymore. A DLL is just a function that is made available to call by any executable (more generally, thread) on the OS. Disclaimer: I'm not a software engineer, but I play one at my office.
Without darkness, there are no dreams. -Karla Kuban
