calling a DLL from a thread

[allynm]

Hello everyone,

I have a math function dll (MathFuncsDll.d ll) with several different functions. I would like to explicitly (dynamically) load one of the functions in a new thread. I use MSFT CreateThread to create the thread and within this call there is a function, let us call it ThreadFunc, that is called. In ThreadFunc I try to load the library (MathFuncsDll.D ll) and call one of the functions in the library. Unfortunately, nothing happens.... Load Library doesn't do anything.

I'm missing something pretty fundamental.

Looking for some guidance.

Thanks,

Mark Allyn

[weaknessforcats]

Do you mean that LoadLibray returns zero for the HMODULE?

If so, have you sopcificed the path to rhe DLL?

Also, are you using C or C++?

If C++ you have to extern "C" on your DLL export functions or GetProcAddress won't be able to find them.

Can you post a little code snippet?

[allynm]

Hi Weaknessforcats :

Thanks for suggesting these possibilities. They were very helpful. I checked them out. I spent most of the day solving the problem, and I guess what I took away from it all was that creating threads is a bit trickier than I realized.

What it came down to was that I needed to put a WaitForSingleOb ject() call with the INFINITE option set. I put this call right after the call to CreateThread() inthe main(). Took a long time for me to figure it out.

But, it works now the way I expected it to. BTW, if you have some advice on when it is better to use LoadLibraryEx rather than just plain old LoadLibrary I would be grateful.

Best regards. And thanks. I'll be back for more, no doubt...

Mark Allyn

[weaknessforcats]

As a general rule, use the Ex version of an API function if there is one.

Since C does not have function overloading, the only way MS can revise arguments is to create a new function.

I'm not sure about your location for WaitForSingle Object.

What you should to is call CreateThread(). That gets your thread started. Next, you need to commnicate with your thread and be able to tell it when to stop. You do this in main() by a call to SetEvent(). This raises a semaphore that the thread can look for. The thread has the call to WaitForSingleOb ject(). The thread should wait for s short period of time and then continue.

That way your thread can run freely until you say stop.

The event requires a CRITICAL_SECTIO N and there are rules about this. You might check MSDN for topics on this.

Also, this material is covered in great detail in Jeffrey Richter's Windows via C/C++.

[allynm]

Hi Weaknessforcats ,

Sorry I've been slow getting back to you with a reply to your last message.

In the two threads I create, all I do in each one is to load a DLL and call a function in the DLL. Because it was a read only operation, I assumed that I didn't need to enter/leave a critical section. This may be a misunderstandin g I have about what happens in thread synch problems. If so, I would be grateful if you would clear up this matter.

So, all I do now is put a WaitForMultiple Objects call immediately after the lines in which I call the two threads. The WaitFor call is in the Main( ).

I have Jeff Richter's Windows via C/C++ book. It is very good, but I am a pretty green novice (as you can see) and I have found his earlier book, Advanced Windows (1997), much easier to understand. I know some of it is now obsolete, but for the sort of trivial stuff I do, it is much more comprehensible.

Thanks,

Mark Allyn

[weaknessforcats]

Do these functions you call on these threads access any common variables? If so, you will need a CRITICAL_SECTIO N regardless. This is to protect against a race on these variables.

It's one thing to have readers only in a database but it's another if these readers are using the same variables in your program.

[allynm]

Hi Weaknessforcats :

The DLL that gets loaded contains an Add function---really trivial. Add does what it says: Adds two numbers. Each thread uses Add. When the threads do the addition, I pass the integers directly to the Add () function in the function signature. The values that are passed in the signature are not variables.

If the variables were global and had the same values, then I suppose I would need to worry about using CriticalSection s?

Thanks,
Mark

[weaknessforcats]

If you are doing:

Add(3,5);

then there's no problem since these will be local variables in the Add() function.

That is, if Add is:

int Add(int, int);

there is never a problem since the arguments are always local variables.

However if you have:

int Add(int*, int*);

then even though the pointers are local variables, the addresses in the pointers are outside the function and therefore open to access by other threads. Now you need a critical section. Further, if this occurs in different processes, then you will need a mutex rather than a critical section. Critical sections only work for the current process.

[allynm]

Hi Weaknessforcats-

Thanks for the very nicely documented and CLEAR reply. I am doing exactly as you indicate in your first snippet. Your third snippet regarding pointers is extremely helpful. I might have tripped up on that at a future time.

I am still playing around with Mutexes (Mutices?). Richter's 97 book is very good on this subject. I was aware of the process-boundedness of critical sections, but a reminder from a pro is beneficial.

Thanks for your generous replies,

Mark Allyn