Author Topic: Using Synchronize in a DLL  (Read 8272 times)


  • Newbie
  • Posts: 3
Using Synchronize in a DLL
« on: April 01, 2010, 04:55:31 pm »
I written an application that loads a DLL. The application also takes care of calling an exported function from the DLL to create and start a thread in the DLL. When the thread is running, it will be listening to packets that arrives at the servicing port. I encountered a problem if I wrapped my calls within the Execute(...) function with Synchronize(...). The application in fact, hang at the first wrapped Synchronize(...) call. However, if I take the wrapper out, the
application seems to be running fine. Previously, before I split my application into a DLL and a caller application, the use of Synchronize(...) posed no problems. But when I use
Synchronize(...) in a DLL, there are problems mentioned above. Thanks and kind regards.


  • Administrator
  • Hero Member
  • *
  • Posts: 11076
  • FPC developer.
Re: Using Synchronize in a DLL
« Reply #1 on: April 12, 2014, 11:21:09 am »
The trouble is that you have two sets of state related to synchronizing, since both the mainprogram and the DLL have a complete copy of the RTL state. (all variables)

To transparently divide a program in to multiple modules (mainprogram and DLLs) you need packages.

A workaround would be to somehow call the tthread.synchronize in the main program (e.g. by callback or so) so that all synchronization is done with only the mainprogram state.
« Last Edit: April 12, 2014, 06:59:54 pm by marcov »


  • Hero Member
  • *****
  • Posts: 1631
Re: Using Synchronize in a DLL
« Reply #2 on: April 12, 2014, 12:27:47 pm »
To transparently divide a program in to multiple modules (mainprogram and DLLs) you need packages.
You mean this url  :)
All posts based on: Win10 (Win64); Lazarus 2.0.10 'stable' (x64) unless specified otherwise...


  • Hero Member
  • *****
  • Posts: 560
Re: Using Synchronize in a DLL
« Reply #3 on: April 04, 2023, 12:17:45 pm »
Been there, more than once :) And am back to the topic this week, looking for other workarounds.

  • Code using threads in a git submodule often used
  • Changing the use to Lazarus packages instead
  • Previously, was using TDLLCompatibleThread that $IFDEF DLLThread used critical sections instead of Synchronize.
  • With packages, $IFDEF no longer seems to be an option
  • IsLibrary is said to be unreliable as well ( seems to indicate this is true for packages).
  • Callback for Synchronize will not do because existing DLLs and other language hosts do not use it.
  • I also use this code in command line tools, some with TCustomApplication, some without.

In this situation, my ideas are:

  • Getting the current modules filename and checking extension for .dll (.so &c) might do, but fails on renamed file extensions,
  • is there a better FreePascal or, if not, operating system call to check if the currently running code is within a library?
  • Sounds like an ugly dependency, but Application.MainForm not being assigned might speak for the code to run from a DLL?
  • if (not Assigned(Application)) or (not (AppInitialized in Application.Flags)) could also indicate that thread synchronization is not available?
  • generally, looking for a way to detect if the synchronize mechanism is available would be better than just guessing by the file type of course


TinyPortal © 2005-2018