"synchronized" method call in dll
-
Hi, I am trying to write a "synchronized" function call in my dll so that programmers that use my api can expect to only make single-instance function calls. The basic motivation is that each function call spawns a thread hence I would like to greatly restrict the number of threads spawned (basically 1-and-only-1 thread spawn per function call to my api). //In my program.h header file int threadCode = 0; //no problem if threadCode is instantiated in the header file HANDLE threadMutexEvent; #define PROC_THREAD 0 #define ERR_THREAD_INUSE 1 //In my program.cpp program file BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { //problem arises if I instantiate threadCode here //threadCode = 0; threadMutexEvent = CreateEvent(NULL, false, true, "MutexEvent"); return true; } int WINAPI processRequest() { WaitForSingleObject(threadMutexEvent, INFINITE); if(threadCode == PROC_THREAD) { threadCode = ERR_THREAD_INUSE; SetEvent(threadMutexEvent); } else { SetEvent(threadMutexEvent); return ERR_THREAD_INUSE; } //spawn thread to do some work for me return 0; } As you can see, I am using Win32's synchronization mechanism to do some simple synchronization on the global variable threadCode. As seen in the code comments listed above, everything is fine if I instantiate threadCode in the header file, however, once I shift the instantiation of threadCode to DllMain the synchronization gets messed up. Basically, seperate function calls to processRequest would always "see" threadCode == PROC_THREAD and go ahead to spawn another thread (which is what I am trying to prevent :() If all things fail I would fall back on leaving the instantiation in the header file, but I am really curious as to why the 2 seemingly identical instantiation calls would result in 2 drastically different results. Thanks
-
Hi, I am trying to write a "synchronized" function call in my dll so that programmers that use my api can expect to only make single-instance function calls. The basic motivation is that each function call spawns a thread hence I would like to greatly restrict the number of threads spawned (basically 1-and-only-1 thread spawn per function call to my api). //In my program.h header file int threadCode = 0; //no problem if threadCode is instantiated in the header file HANDLE threadMutexEvent; #define PROC_THREAD 0 #define ERR_THREAD_INUSE 1 //In my program.cpp program file BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { //problem arises if I instantiate threadCode here //threadCode = 0; threadMutexEvent = CreateEvent(NULL, false, true, "MutexEvent"); return true; } int WINAPI processRequest() { WaitForSingleObject(threadMutexEvent, INFINITE); if(threadCode == PROC_THREAD) { threadCode = ERR_THREAD_INUSE; SetEvent(threadMutexEvent); } else { SetEvent(threadMutexEvent); return ERR_THREAD_INUSE; } //spawn thread to do some work for me return 0; } As you can see, I am using Win32's synchronization mechanism to do some simple synchronization on the global variable threadCode. As seen in the code comments listed above, everything is fine if I instantiate threadCode in the header file, however, once I shift the instantiation of threadCode to DllMain the synchronization gets messed up. Basically, seperate function calls to processRequest would always "see" threadCode == PROC_THREAD and go ahead to spawn another thread (which is what I am trying to prevent :() If all things fail I would fall back on leaving the instantiation in the header file, but I am really curious as to why the 2 seemingly identical instantiation calls would result in 2 drastically different results. Thanks
Hi I think the reason is that in the first case (var in header) initiation is only one time execution, but in the second case depends on dll instance. I think your variable have to be static, try that way Regards David
-
Hi I think the reason is that in the first case (var in header) initiation is only one time execution, but in the second case depends on dll instance. I think your variable have to be static, try that way Regards David
Hi David, Thanks for the reply. I have tried using static and got the same result. I am quite sure only one instance of the dll is being loaded each time my test application is using it as I have other code in DllMain that clears the UI of all user input (which I don't see happening). Thanks
-
Hi David, Thanks for the reply. I have tried using static and got the same result. I am quite sure only one instance of the dll is being loaded each time my test application is using it as I have other code in DllMain that clears the UI of all user input (which I don't see happening). Thanks
Another idea is replace current sync code instead a simple critical section. You have to init cs in DllMain I think that should work and is simple. David
-
Hi, I am trying to write a "synchronized" function call in my dll so that programmers that use my api can expect to only make single-instance function calls. The basic motivation is that each function call spawns a thread hence I would like to greatly restrict the number of threads spawned (basically 1-and-only-1 thread spawn per function call to my api). //In my program.h header file int threadCode = 0; //no problem if threadCode is instantiated in the header file HANDLE threadMutexEvent; #define PROC_THREAD 0 #define ERR_THREAD_INUSE 1 //In my program.cpp program file BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { //problem arises if I instantiate threadCode here //threadCode = 0; threadMutexEvent = CreateEvent(NULL, false, true, "MutexEvent"); return true; } int WINAPI processRequest() { WaitForSingleObject(threadMutexEvent, INFINITE); if(threadCode == PROC_THREAD) { threadCode = ERR_THREAD_INUSE; SetEvent(threadMutexEvent); } else { SetEvent(threadMutexEvent); return ERR_THREAD_INUSE; } //spawn thread to do some work for me return 0; } As you can see, I am using Win32's synchronization mechanism to do some simple synchronization on the global variable threadCode. As seen in the code comments listed above, everything is fine if I instantiate threadCode in the header file, however, once I shift the instantiation of threadCode to DllMain the synchronization gets messed up. Basically, seperate function calls to processRequest would always "see" threadCode == PROC_THREAD and go ahead to spawn another thread (which is what I am trying to prevent :() If all things fail I would fall back on leaving the instantiation in the header file, but I am really curious as to why the 2 seemingly identical instantiation calls would result in 2 drastically different results. Thanks
Sorry, but I think that is not a good idea put a Global var in a header file. Put all global vars in the cpp file. In the header file only function ptototypes. Regards David
-
Sorry, but I think that is not a good idea put a Global var in a header file. Put all global vars in the cpp file. In the header file only function ptototypes. Regards David