use single threaded dll in threads

[coffee]

hi all,

i have a single threaded dll, that i want to run in 4 threads in my program.
is there a way to loading multiple instances of a dll explicitly and use them in my program?

thank you for any help.

[skywalk]

Huh?
How do you guarantee the 4 calling threads will not step on the same variables in the dll?

[mk-soft]

I don't think you need four instances, just another way to process data with thread.

Code: Select all

Structure udtThreadData
  ThreadID.i
  Exit.i
  State.i
  ; Data
  var1.i
  var2.i
EndStructure

Global thData1.udtThreadData
Global thData2.udtThreadData

Procedure thWork(*data.udtThreadData)
  With *data
    Repeat
      Delay(100)
      \var1 + \var2
    Until \exit
  EndWith
EndProcedure

thData1\var2 = 10
thData1\ThreadID = CreateThread(@thWork(), thData1)

thData2\var2 = 200
thData2\ThreadID = CreateThread(@thWork(), thData2)

Delay(2000)
thData1\Exit = 1
thData2\Exit = 1

While IsThread(thData1\ThreadID) : Delay(50) : Wend
While IsThread(thData2\ThreadID) : Delay(50) : Wend

Debug "Data1 = " + thData1\var1
Debug "Data2 = " + thData2\var1

[coffee]

i am not so sure, that i understand that "just another way to process data with thread".
the dll (pdfium) has global variables and static data - so it is not thread safe. I like to use the dll several times at the same time, for sake of the argument 4 (n) times.
how can i load that dll 4 (n) times, so that it does not share the global variables and static data in memory and i can call the dll instances safely from my own threads?

thank you in advance for your insights.

[srod]

Well, not a problem for different processes loading the dll since they effectively get their own copies of the global variables, but multiple threads within a single process... yes that's a problem! No problem with local variables as each thread gets it's own stack of course. Are you sure that pdfium uses global variables as opposed to threaded variables via thread local storage? I would find that surprising for such a library. Surely there is a version of pdfium that has been compiled for thread safety?

As I see it you would probably need to employ a PB mutex object to prevent threads accessing the dll 'simultaneously'. This of course effectively renders the operation of the dll as single threaded and there is still the scope for data corruption as each thread still has indirect access to the said global variables - just not simultaneously. It just depends on what those global variables are used for?

Another possible option, if these global variables have been exported so that you can import them directly, is to create a wrapper around them and switch their values for threaded values prior to any call to the dll. You would still require a mutex mind and you would need a good understanding of what these globals are being used for. Undoubtedly a long shot this one.

**EDIT : I am unsure of the answer to this one, but can you not simply make 4 renamed copies of the dll and load separately? Would that work? I am assuming of course that your 4 threads are working on separate pdf files.

[coffee]

most of the pdf dlls like debenu etc. and pdfium are single threaded and i can't find any dll that has been compiled for thread safety.

the mutex solution is kind of out, but having multiple copies of the dll is an (ugly) option. i thought someone would know some trick - maybe.

Thank you for your suggestion.

[srod]

Reading around a bit (and I am sure you have done that yourself far more than I have) and even the creators of pdfium recommend spawning separate processes to work on separate pdf documents etc. Probably your best option.

[coffee]

yap, but i have to say your idea with renamed dll's works. i just make as many copies of the original that i need and delete them when i am done.

thanks again for that idea.

[srod]

Interesting. I couldn't see any reason why that shouldn't work, but wasn't 100% sure.

[mk-soft]

I thought if you open the DLL several times with OpenLibrary the PB will also create multiple instances.
But this is not so. It looks like the DLL depends on the process instance and is loaded only once.

How it looks when you open a DLL in the thread I haven't tried yet. Then it must be an own process instance. But it's not sure that the function is OpenLibrary Threadsafe.

[srod]

The LoadLibrary_() API function will return a handle to an existing open instance if the DLL is already loaded. It will not load it multiple times into the same app process address space regardless of whereabouts in the application it is used whether it is in a thread or the main process. So the threadsafety, or otherwise, of LoadLibrary_() is not an issue.

[coffee]

yes.
with the renamed copies it works like a charm.

How it looks when you open a DLL in the thread I haven't tried yet.
all the same, you must have a copy.

[skywalk]

Unfortunately, making dll copies at runtime is flagged by most antivirus machines.
Are you able to make the copies before running your app?
Antivirus also takes notice of your app spewing exe's to achieve:
RunProgram("MyExe1+1thread.dll") +
RunProgram("MyExe2+1thread.dll") +
RunProgram("MyExe3+1thread.dll").
The dll should be isolated in this case.

[coffee]

i had no problem with that yet, but is there a way to load the a dll into memory and call it from there?
i guess then the antivirus should not have a problem.