Is the Synchronize method of a thread able to execute when the thread is Suspended?

e.g if the following instructions are executed in succession

    Synchronize(@DispatchOutput);
    Suspend;

After the Execute has performed an instance of the thread's main task, I want the to wait until the Synchronize is performed by the main thread, so the Resume is executed in the Synchronize(@DispatchOutput) code. Is that a correct way of working?

Synchronize(@DispatchOutput); Suspend;

That is not necessary because Synchronize always waits for the command to complete.

Cheers,
Tobias

What are you trying to accomplish ?

"Synchronize"
- Sends a message to the main thread
- makes the thread stall
- now the main thread preforms the synchronized method
- now the main thread makes the thread run again.

This prevents the thread and the main thread use critical resources concurrently, but it also prevents the thread from working permanently but stalls it for an indefinite amount of time while the main thread is busy with other stuff before it gets to doing the synchronized method.

"Suspend" just makes the thread stop and makes it wait for some other thread to wake it.

So the use of "Synchronize" and "Suspend" is unrelated.

-Michael

I want the thread to be activated only a certain number of times every few minutes, so if it is not yet time to run the thread or it has run only recently Resuming should not execute until time is ready.

I also want to stop it if it has been running too long without responding, or its main routine has not yet returned. I am essentially running command line programs which may not return their output in good time without affecting the main thread, network monitoring/polling in an uncertain networking environment.

On 07/12/2010 02:27 PM, Frank Church wrote

I want the thread to be activated only a certain number of times every few minutes

Maybe you better use a TTimer callback event instead of a thread. The purpose of (worker-)threads is to do (fast) work in the background.

-Michael

The code is running in a TProcess executing command prompt programs rather than from an API, and I thought the issue of waiting for the result makes it better if they are run in threads.

My preferred approach is that even if the thread is suspended during the Synchronize period, it should remain suspended until a timer running in the main thread kicks it of again. I think testing the thread's *while not terminated* loop to see if it is time yet is an inefficent use of resources

Frank Church wrote

The code is running in a TProcess executing command prompt programs rather than from an API,

You mean it's a no-GUI project ?
In fact, at the moment, Lazarus lacks a Application Template and Widget Type for programs that need TTimer (and similar things) but are supposed to run in a (Linux) system that does not provide a GUI API, Here using Threads can be a work-around.

Do you in fact want to run your program on a system that does not provide a GUI API ? Otherwise you can just do a normal (GUI enabled) application and hide the main form.

Of course you are right that "busy spinning" always is a bad idea. As said, a suspended thread needs to be woken by another thread. In most cases there are better synchronizing options than using "suspend". (TEvent, TCriticalSection, ...)

-Michael
(BTW.;: Do not top-post. This makes the Forum Thread hard to read.) -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100713/42ff67a3/attachment.html>