views:

137

answers:

2

I'm writing a dll library in Delphi with multiple threads created by it. Let me describe the problem step by step. I'm sorry for a lengthy description in advance :-(.

Let's forget about the library for a while. I created a windows application that is going to present views from several cameras. I created a window which is meant to show the view from a single camera and it contains a TImage control. There is a thread (a TThread descendant) that downloads the current image from the camera every couple of milliseconds and assigns it to the TImage control of that window (using the Synchronize() method). The application creates several instances of that window on startup (with a separate thread for each of them), so you can see the live view from several cameras at once. What's more, all those viewing windows are parented by the main application window, so they appear within it.

Everything worked fine until I decided to put those two windows into a dll library. I just found it necessary for some reasons, but they are not important now. So I created a new dll library, added the existing main window and the camera-view window to the project and exported a function that creates and returns an instance of the main window. When the main window is created, it creates several camera-view windows, making itself their parent.

Then, for testing purposes, I created an app that imports the above mentioned dll function from the library and calls it at startup to get an instance of the main window; then just shows it on the screen (in a non-modal state).

When I started the app it came out that I couldn't get a single image from any camera then. When I debugged it, I noticed that when the thread calls the Synchronize() method, it hangs forever. It didn't happen before putting both those windows into a dll.

And this is my problem. To be honest, this is my first approach to libraries I have had to get through many other problems so far. You might wonder why I use windows instead of frames... So whenever I created an instance of a TFrame in a dll, I would get an exception saying "the control xxx does not have a parent window". I did not know what to do about that so I used windows instead :-(.

Could you please tell me what to do with the synchronization problem? The main thread does not seem to be blocked in any way when the application is started for it accepts clicking buttons etc. What is the problem then?

Please, help!

Thank you in advance!!

+9  A: 

When you call TThread.Synchronize the thread and method pointer are added to a global SyncList TList in Classes.pas. In the main exe's TApplication.Idle routine calls CheckSynchronize, which checks the SyncList, but it's going to check the version in the exe instead of the one in the DLL. End result, your synchronized methods are never called.

The easiest fix would be to switch from DLLs to packages, which would eliminate the duplicate SyncList.

Another approach would be to override the exe's Application.OnIdle callback, and call your DLL's CheckSynchronize manually. You would need some help from the application for that though, since your DLL will have an Application object too, and that one won't work.

Craig Peterson
Thanks for the answer. Now I know there's no point in looking for an error in my code :-). I'm wondering if I could use SendMessage() instead of Synchronize(). I can't check it at this moment, so let me ask you what you think about this idea. I think the main thread should process a message sent to a window created by it, right?
Mariusz
BTW, is it OK that when I create an instance of a TFrame descendant in a dll, I get those exceptions I mentioned ("the control '...' has no parent window")? Am I doing something wrong or is it just impossible? Thanks!
Mariusz
@Mariusz, using SendMessage should be fine. The thread that creates a window is always the one that processes messages sent to that window. For your second comment, please post that as a new Stack Overflow question. It's not simply a follow-up to this question about synchronizing threads.
Rob Kennedy
Thanks a lot. OK, I will add a new question in a minute. Greetings!
Mariusz
+2  A: 

It's a bad idea to use Synchronize, because it tends to lead to race conditions like this. I don't know what's going on specifically in your code--it's hard to tell without seeing any code--but this sort of issue is pretty common actually.

Inter-thread communication is better done with a queue. If you've got the latest version, Delphi XE, there's a TThreadedQueue<T> class in Generics.Collections that's ideal for this sort of thing. Pass 0 to the PopTimeout param in the constructor, have your camera threads push images, and have your main thread poll the queues with the third PopItem overload, like so:

var
  CurrentItem: TImage;
begin
  if ThreadQueue.PopItem(CurrentItem) = wrSignaled then
    UpdateImage(CurrentItem); //or however you do it
end;

(If there's nothing in the queue, PopItem will return wrTimeout instead.)

If you don't have Delphi XE, you'll need to build your own threadsafe queue, or find one from a third party source, such as Primoz Gabrielcic's OmniThreadLibrary.

Mason Wheeler
I have got BDS 2006 :-/. I'm considering the use of SendMessage() instead of Synchronize(). I have to check that out tomorrow. Thanks for your answer anyway. I didn't know about this kind of queues and they may certainly be useful sometimes.
Mariusz
@Mariusz: Neither use `Synchronize()` nor `SendMessage()`, there's no need for that tight coupling between producers and consumer of the images. So what if an image is shown a little bit later or not at all, because the next one is already available? Use `PostMessage()`, don't store the image in the message (use a real thread-safe variable for it) and use a single image variable for each producer instead of a queue.
mghie
I have already tried it before creating the dll and it worked fine. You're right. I used a critical section to synchronize the access to the image, and the thread refreshed it all the time but posted a message only when the main thread has already processed the previous one. I think you are right. This is safer; I will not have to worry about the application hanging up then for it won't happen. Thanks.
Mariusz
BTW, how would you pass exceptions to the main thread? I would just like to inform user about possible problems happening in the thread (like inability to download a picture). Should I do it the same way? Use a Exception variable and post a message to the interface so it reads it then?
Mariusz