THreads, dlls, and UDP


I have a service appication that starts three threads. These threads all
call a DLL to send a message using UDP. The dll uses the UDPClient
component (I think its called that). Somewhere in all this I find that the
call to send the message via UDP causes an exception.

This dll has been used many times over a long period of time, but never from
a thread, and never more than once per machine.

So I wonder if my dll needs to be "thread safe" and what does this mean Or
could it be that the calls to the UDPClient are occuring symultaneously and
therefore causing the problem

Any advice would be welcome.


Posted On: Tuesday 16th of October 2012 03:37:39 AM Total Views:  357
View Complete with Replies

Related Messages:

Do are TStringList.Add and TStringList.Delete methods threadsafe?   (197 Views)
"Ahmadi" wrote in message > im not sure that these methods are threadsafe or no. No, they are not. Most of the VCL in general is not thread-safe. > If they are not threadsafe, anyone know where can i find > a threadsafe TStrings class that be threadsafe You don't need a specialized class for that. Just use a separate TCriticalSection to serialize access to your existing TStringList. Gambit
Example of threads on a dual core   (125 Views)
Is there a simple example or thumbnail sketch of how to execute two threads on different cores of a dual-core CPU -- Replace you know what by j to email
Creating event procedures using threads?   (231 Views)
I am working on a class to implement data retrievel over the Internet. When the data are retrieved there will be a rather long time before it is done and I would like to create events inside the class to make it possible in the host application to show progress information and maybe also some messages. I know how to make event properties in a class and how to check if it has been assigned and if so call the method. But this may break the communications function if the host application is not well behaved and exits the function quickly. If this happens (for example if the host starts to do some lengthy operation in the event code) then the data transfer will be put on hold. So I ask myself if it could be solved with threads instead But I don't know the answer so I ask here. Basically I have something like this: type TMyMessageEvent = procedure(Sender: TObject; Msg: string) of object; TNyCommObject = class private FOnSomeEvent: TMyMessageEvent; .... public ... property OnSomeEvent: TMyMessageEvent read FOnSomeEvent write FOnSomeEvent; end; procedure TMyCommObject.HandleData; begin {Retrieve the data in a long loop} {in the loop on some condition fire off event} if MyCondition and Assigned(FOnSomeEvent) then FOnSomeEvent(Self, 'Something happened'); end; Here I would like to *not* call the event procedure in the host application directly but instead create a thread that executes the code while the main object code can continue processing the data. What would be the best approach for such a solution If possible a code example is appeciated. -- Bo Berglund
Help needed with threads   (141 Views)
Goal: I've got some code (TProcessor.Process) that takes a while to run, and I want a modal form with a progress bar (ProgressForm) to show the progress of this task. My basic design is to run this method in a thread, i.e.: A thread class (TProcessThread) takes a reference to this object, and in it's Execute method simply calls the long taking method (TProcessor.Process). TProcessor.Process interacts with a TGlobalData class and mainly calls it's Step method. GlobalData fires an event when it's data changes. This event is handled by the TProcessThread and calls a method (via Synchronize) that updates the ProgressBar on the ProgressForm. The whole thing is started by ProgressForm.RunTask which: Creates the thread (TProcessThread) and then calls ShowModal. The thread's OnTerminate event includes code to close the form. This works fine in simple cases, but in my application that includes more complex processing in the "process" method, it sometimes hangs. I have posted a sample application in attachments, which works fine, but I'm hoping that someone with more experience can spot the weakness of this scheme, that results in problems in more complex cases. If I step through the code (and therefore the form in not shown) the problem (mostly) doesn't occur. But if I run normally then it does.