Thread: Management variables in a multithreaded dll?

Hi,

Here is my problem:

I am spirited coding java interface to perform various tasks (eg video encoding, audio (de) multiplexing, encryption, etc.).

Most of these operations are performed by C / C + +. J'interface therefore necessary C functions via JNI (Java Native Interface Using C function in Java) which requires recompiling the C / C + + as dll. Until not the problem.

Now I can run multiple identical tasks simultaneously (eg two audio encodings) which will then use the same dll.

Each thread is launched from Java (java.exe [| javaw.exe]) and so they all run in the same process. I therefore income follows a similar case a prog C / C + + that generates multiple threads, each of which can be used "simultaneously" to a single function of a dll.

1. I guess I should compile my dll with multithreaded. YES | NO?

2. How ca this place internally in the variables? Is that AC is a problem of sharing even if a function is called simultaneously by 2 threads of the same process? (I ask this because I think the dll provides an instance of code per process, not per thread).

3. The prog C / C + + Original contains global variables that are shared between all processes that use the dll (well, I think). Someone was there an idea that I could manage a sort of environmental thread (eg if we can execute a function of the thread takes the hand and affect global variables with hers)?

UP because it interests me (albeit old).

1. I reckon it's clear

2. Insofar as the process has a single address space. So the global variables (static or not) will be accessed by all threads in the same. The most important features used by threads is that they are reentrant, meaning that all items are local variables (passing parameters and local variables). From the moment you introduce a global variable or dynamic multi-joint thread, you are obliged to maintain a mutex reader / writer.

3. For global variables DLLs, depending on whether they are static or not (and I seem to remember that the list of visible symbols of a DLL must be given explicitly). And to answer your question, the solution is to reentrancy with a pointer to a context (a struct after all) dynamically allocated when creating the thread.

That's what I wanted to know, and I checked for myself.

I will explain my case. I use a library that made the calculation. It uses, in "internal" global variables. For me, a priori, regardless of when the outcome is good.

I start the computation in a thread, so good. But I decided to start a 2nd (in another thread) and then the results are delusional. This is due to those famous global variables that can not be used for many calculations simultaneously.

I decided just to try because I did not have clear info on it, create a DLL (with the functions and global variables of the library in question) and explicitly load (via LoadLibrary and GetProcAddress) this DLL in each thread. Just to see if they access the same memory space or if the variables are duplicated.But no, I have the same problem as I feared.

The only solution I see is to remove these global variables in 2 ways:
1) make local and make crossings address
2) create a class with member variables
But this library is enormous, not just to "manage" so I n'enviseage none of these 2 solutions.

Knowing that I do not think there is any "dead time" (each thread is completely independent and must turn "bottom") is there another solution that I do not know?

What you say in fact that is not reentrant!

The scope of the class member variables is like using a context (a struct) single thread. Finally, if you want some elements common to many thread there are only 2 scenarios:

1. Non-reentrant
He must manage a mutex to access the resource (the function or variable selection)

2. Reentrant
Having variables calculations in a memory area "reserved" to the calling thread. Typically, the stack CAD local variables and parameter passing.

Ok, so:

- Or I use the mutex, which means I suppose there will be "dead time".
- The reentrancy, using one of 2 methods that I mentioned.
- I is not understood what you said

There are other options, it makes A bit more complicated.

On the one hand there is the cutting logic, partly due to language. Very briefly, the "global" require arbitration. We may, by order of decreasing wave cost and increasing siouxerie, either use the OS - the famous semaphore / mutex / etc - but it is expensive especially when it involves restraint and the scheduler, or self-regler exlusif the same example with spinlocks, or use of lock-free structures or more wait-free, or ensure coherence by using atomic primitive - in the broadest sense. The last two options overlap and can be particularly difficult to implement.

But there is no distinction that "logic", a NUMA machine - say a babasse with several AMD processors - there is actually a local memory. It is therefore especially important to pay attention to the locality. The battery, even on an OS like moldy xp is allocated locally. Afterwards, it becomes more difficult, a revenue is otherwise use VirtualAlloc and / or touching the memory on each page. Or TLS, but it is flawed.

I had the same problem with a library of decomposition of convex geometry (for small convex hulls for collision physics engine), I did as, I made an external process + memmap.

Since I still have my flag on this topic, I give you the solution I finally adopted my problem. The DLL in question, I have duplicate (both file that thread) and each was loaded dynamically by a thread. So, each thread accesses a different memory space and everything is going well despite the global variables.

It was by far the most simple and fastest changing the library was not a reasonable alternative (in terms of time).