Multithread problem with DLL
-
Hi. I'm developing a program with visual C++ that creates multiple threads and each thread creates a new instance of the same DLL (which I have the the code, but I didn't developed it). The problem I'm having is that when I create the first thread, the DLL is instantiated correctly but when I create the second thread and try to create a new instance of the dll, I didn't actually create a new instance, but just makes an instance of the DLL already instantiated, and so I overwrite some variables and stuffs like that. If, instead create two threads I execute the program twice, running at the same time, I can make new instances of the DLL. Why in this way I can make a new instance of the DLL and using threads I can't? How do I know if the DLL was created as a multithreaded DLL? And another question is if the DLL wasn't created a multithreade DLL, how can I change this? Dennis
-
Hi. I'm developing a program with visual C++ that creates multiple threads and each thread creates a new instance of the same DLL (which I have the the code, but I didn't developed it). The problem I'm having is that when I create the first thread, the DLL is instantiated correctly but when I create the second thread and try to create a new instance of the dll, I didn't actually create a new instance, but just makes an instance of the DLL already instantiated, and so I overwrite some variables and stuffs like that. If, instead create two threads I execute the program twice, running at the same time, I can make new instances of the DLL. Why in this way I can make a new instance of the DLL and using threads I can't? How do I know if the DLL was created as a multithreaded DLL? And another question is if the DLL wasn't created a multithreade DLL, how can I change this? Dennis
This is not about multithreaded dll - this is how the windows handles the dll libraries - it is loaded only once in the memory for saving resources. When you call subsequent
LoadLibraryit simply increments the usage counter. If youLoadLibraryfrom other process, it is a different story. There are some nifty stuff inside the windows, but for you it's like the dll is loaded again --> you can load your library only once into process memory. Difference between library compiled as multithreaded or singlethreaded is AFAIK only difference with c runtime support libraries used. If you will not use functions likeprintfetc, there is no difference between dll compiled as multithreaded or singlethreaded. There's no way, how to determine, if the dll was compiled as multithreaded, neither way how to change it (without having sources and recompile). But for your problem as you described, it makes no difference I guess. -
This is not about multithreaded dll - this is how the windows handles the dll libraries - it is loaded only once in the memory for saving resources. When you call subsequent
LoadLibraryit simply increments the usage counter. If youLoadLibraryfrom other process, it is a different story. There are some nifty stuff inside the windows, but for you it's like the dll is loaded again --> you can load your library only once into process memory. Difference between library compiled as multithreaded or singlethreaded is AFAIK only difference with c runtime support libraries used. If you will not use functions likeprintfetc, there is no difference between dll compiled as multithreaded or singlethreaded. There's no way, how to determine, if the dll was compiled as multithreaded, neither way how to change it (without having sources and recompile). But for your problem as you described, it makes no difference I guess.There are quite a few run-time library functions that have global/static variables whose storage specification changes for the multithreaded versions. The multithreaded versions use the __declspec( thread ) keywords to specify thread-local storage for those variables which means that each thread gets its own copies of each variable.
-
Hi. I'm developing a program with visual C++ that creates multiple threads and each thread creates a new instance of the same DLL (which I have the the code, but I didn't developed it). The problem I'm having is that when I create the first thread, the DLL is instantiated correctly but when I create the second thread and try to create a new instance of the dll, I didn't actually create a new instance, but just makes an instance of the DLL already instantiated, and so I overwrite some variables and stuffs like that. If, instead create two threads I execute the program twice, running at the same time, I can make new instances of the DLL. Why in this way I can make a new instance of the DLL and using threads I can't? How do I know if the DLL was created as a multithreaded DLL? And another question is if the DLL wasn't created a multithreade DLL, how can I change this? Dennis
It sounds to me like your problem is with global variables in the DLL - i.e. there's only one variable X but when you run two threads they'll both be able to change it. Same thing applies to any static variables in functions. If this is the problem then it implies that the DLL's author wasn't expecting the DLL to be run in different threads in which case it assumedly wasn't linked with the Multithreaded runtime libraries which will create a different set of issues. A solution is not too easy. You could: 1. Use thread local storage (see "Using Thread Local Storage in a Dynamic-Link Library" in the SDK documentation) to sort out the variables (or use __declspec(thread) which might be easier). However, you will need to understand which variables should and which shouldn't be accessable to all threads. 2. Re-build using the mutli-threaded libraries. However, You might still have issues with any resources the DLL uses (such as intentionally shared variables). To sort this out you'd need to use some type of synchronisation object such as a mutex (or create a critical section) to control multi-threaded access. There's lots of stuff about this in the SDK. Depending what the DLLs actually does, it might be easier to rewite it yourself or look for an alternative.
-
There are quite a few run-time library functions that have global/static variables whose storage specification changes for the multithreaded versions. The multithreaded versions use the __declspec( thread ) keywords to specify thread-local storage for those variables which means that each thread gets its own copies of each variable.
Thank you. Didn't know it. Or better didn't think about :cool: I just got it as - I don't know which functions have some global/static parts and I don't know if it can or cannot change. Therefore I decided to took the run-time library as a block - either use it, but then compile carefully with appropriate switch or dump it completely.
-
This is not about multithreaded dll - this is how the windows handles the dll libraries - it is loaded only once in the memory for saving resources. When you call subsequent
LoadLibraryit simply increments the usage counter. If youLoadLibraryfrom other process, it is a different story. There are some nifty stuff inside the windows, but for you it's like the dll is loaded again --> you can load your library only once into process memory. Difference between library compiled as multithreaded or singlethreaded is AFAIK only difference with c runtime support libraries used. If you will not use functions likeprintfetc, there is no difference between dll compiled as multithreaded or singlethreaded. There's no way, how to determine, if the dll was compiled as multithreaded, neither way how to change it (without having sources and recompile). But for your problem as you described, it makes no difference I guess.I'm not using LoadLibrary method. I'm importing the .tlb of the DLL file and then linking to my program. To create a new instance of the DLL, im using the methods CoInitializeEx with the parameters 0 and COINIT_MULTITHREADED and then CoCreateInstance with the parameters CLSID_DLL, NULL, CLSCTX_ALL, IID_IUnknown, (LPVOID*)&pointer);
-
It sounds to me like your problem is with global variables in the DLL - i.e. there's only one variable X but when you run two threads they'll both be able to change it. Same thing applies to any static variables in functions. If this is the problem then it implies that the DLL's author wasn't expecting the DLL to be run in different threads in which case it assumedly wasn't linked with the Multithreaded runtime libraries which will create a different set of issues. A solution is not too easy. You could: 1. Use thread local storage (see "Using Thread Local Storage in a Dynamic-Link Library" in the SDK documentation) to sort out the variables (or use __declspec(thread) which might be easier). However, you will need to understand which variables should and which shouldn't be accessable to all threads. 2. Re-build using the mutli-threaded libraries. However, You might still have issues with any resources the DLL uses (such as intentionally shared variables). To sort this out you'd need to use some type of synchronisation object such as a mutex (or create a critical section) to control multi-threaded access. There's lots of stuff about this in the SDK. Depending what the DLLs actually does, it might be easier to rewite it yourself or look for an alternative.
About the item 1, I will analyze further the method __declspec(thread) and try to use it. But in the 2nd item, you told me to rebuild DLL using the multi-threaded libraries. In Visual C++ 6, Project->Settings, C/C++ tab with Code Generation option selected, it has an combo box called "Use run-time library". The option selected there already is "Multithreaded DLL". There's another way to configure this? How it does? Dennis
-
About the item 1, I will analyze further the method __declspec(thread) and try to use it. But in the 2nd item, you told me to rebuild DLL using the multi-threaded libraries. In Visual C++ 6, Project->Settings, C/C++ tab with Code Generation option selected, it has an combo box called "Use run-time library". The option selected there already is "Multithreaded DLL". There's another way to configure this? How it does? Dennis
I was only assuming that the DLL was built without the Multithreaded option on because you said you were getting these problems. If the option's already set then that's fine. By the way __declspec(thread) isn't a method. It's a storage class modifier. For example if you want to define a static variable in a function then you would use: __declspec(thread) static int MyVar; You'll find more about this here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_the_thread_attribute.asp[^]
-
I'm not using LoadLibrary method. I'm importing the .tlb of the DLL file and then linking to my program. To create a new instance of the DLL, im using the methods CoInitializeEx with the parameters 0 and COINIT_MULTITHREADED and then CoCreateInstance with the parameters CLSID_DLL, NULL, CLSCTX_ALL, IID_IUnknown, (LPVOID*)&pointer);