5

I have this static C library that I need to run multithreaded(the threads have no interaction with each other, I just need multiple of them at the same time to get stuff done faster). Further more I've wrapped the c library into a c++cli library which is then used by the c# main application.

Since the static library doesn't respond well to multiple threads running through it (which is out of my control, I don't have the source for its dependencies), I have resorted to copying(with slight variations) the whole thing multiple times and putting another wrapper between the c++cli library(and its copies) and the c# application that emulates the copies as up to 8 instances of the object. It works but its rather crude and cumbersome to make any changes to the functionality of the library.

Does anybody know of a simpler way to achieve the same effect? Best guess I have is that some static piece of memory is where the conflict arises between multiple threads working in the same library, is there a way to force all the static variables to be thread specific? (without the ability to go in an add declspec thread to them).

Jake Freelander
  • 1,471
  • 1
  • 19
  • 26
  • 2
    `I have resorted to copying(with slight variations) the whole thing multiple times`. How exactly does it help? If you are changing names of global/static variables so that there are no conflicts, you can designate them as tread local just as well. If you are not changing names, what are these slight variations? – n. m. could be an AI Sep 05 '14 at 09:57
  • library names so they get loaded as "different" things – Jake Freelander Sep 05 '14 at 10:02
  • 5
    Static libraries are not loaded, they are linked. Library names have no effect on static libraries linkage process. DLLs on Windows may behave as you describe, but not static libraries. – n. m. could be an AI Sep 05 '14 at 10:11
  • Reminds me of a problem I once had with function `localtime` being thread-unsafe. Some users suggested that I'd use function `localtime_r` (the thread-safe version) instead. It wasn't a feasible solution in my case, since the SDK that I was using did not provide that function, but I think it might answer your question in a certain way. You should probably wrap each of your access operations to static variables in that library with an appropriate protection resource (e.g., Mutex). I guess that this is similar to what `localtime_r` does before calling `localtime`. – barak manos Sep 05 '14 at 10:12
  • @n.m. there are both .lib and .dll files involved, I don't know which of them are causing the issue so I did it for all of them – Jake Freelander Sep 05 '14 at 10:14
  • This is still suspicious. If you change *only* library names, it may have effect if you use the library with LoadLibrary and GetProcAddress. If you *link* it, you need to change something beyond library names. – n. m. could be an AI Sep 05 '14 at 10:43
  • @n.m. It's set up like this: the main logic c library requires a bunch of other libraries, some are supplied with source, others with .lib and header file and some require .dll to actually run. All these dependencies are taken care of in the c++cli project which wraps around the main logic library. Then I make a bunch of these c++cli dll's that are almost identical, except the main class name is different and the name is different. Then the wrapper on top of the wrapper hides the different names and makes it look like they are instances of the same class. – Jake Freelander Sep 05 '14 at 15:16
  • Ah, this makes sense. Do you also rename your subordinate DLLs? If an executable loads A.dll and B.dll and each of those loads C.dll, you have only one instance of C.dll. – n. m. could be an AI Sep 05 '14 at 15:51
  • 4
    A radical solution would be to do away with threads and just run separate processes. – n. m. could be an AI Sep 05 '14 at 15:55

2 Answers2

1

Since you are using your C library from C# via C++/CLI layer, it sounds like your link relationships look like this:

(C# application)--dynamic-->(C++/CLI DLL)--static-->(C library)

Background:

Because you stated that you have no way of modifying or otherwise fixing your C library, you really have no way of solving the thread-safety problem without duplicating the C library in memory somehow, which will effectively duplicate the global data which is/are certainly causing the threading conflicts.

No matter how you look at it, your only way of solving this via DLL duplication (your current approach) will require you to know how many duplicates you need ahead of time, and each one of those DLLs will need slightly different exported symbol names (for example, each will need a different class or namespace name for your C++/CLI managed object class). As you stated, this is indeed crude (and I will add hard to manage and impossible to scale).

Solution:

I think your better and cleaner option is via EXE duplication. For this, you will insert a new EXE in front of your C++/CLI DLL and link to it dynamically via IPC mechanism of your choice (IPC Mechanisms in C# - Usage and Best Practices). Lets call this EXE your service EXE. If you instantiate a service EXE for each thread in your main C# application, then each service EXE will load its own copy of the C++/CLI DLL and consequently its own version of the C library. This means that each thread is operating on a copy of the C library via a service EXE.

Here is what your link relationships would look like:

(C# application)--IPC-->(C# service EXE)--dynamic-->(C++/CLI DLL)--static-->(C library)

In physical file terms, it would look like this:

MainApp.exe--IPC-->ServiceApp.exe--dynamic-->CppCliWrapper.dll

To optimize this solution, you should try to avoid heavy thread creation / deletion since that involves creation / deletion of a service EXE. For example, you might pre-allocate X threads on startup and use those threads throughout your application lifecycle. You might also consider batching your operations to optimize the IPC overhead. All of this depends on the needs and details of your application.

To take this even further, you could potentially scale this solution across machines if you choose an IPC mechanism that works over TCP/IP. You could then farm out your operations across as many machines as you like. This is how a lot of companies turn DLLs into horizontally scalable services. It's not as easy as it sounds, but food for though in case you need to scale this thing up.

Community
  • 1
  • 1
Nicholas Smith
  • 975
  • 7
  • 18
0

The problem seems to be that the library is not re-entrant. If you have access to the library source code, your best bet is to do a search for all global variables and make them thread local. This can be done using the thread_local keyword on C++11 or using the __thread keyword if compiling with gcc/g++.

This ensures that a different copy of each global variable will be used on each thread.

doron
  • 27,972
  • 12
  • 65
  • 103