<p>Am 13.05.2015 10:53 schrieb "Michael Schnell" <<a href="mailto:mschnell@lumino.de">mschnell@lumino.de</a>>:<br>
><br>
> On 05/12/2015 05:39 PM, Sven Barth wrote:<br>
>><br>
>><br>
>> Why should that interfere in any kind?! Behind the scenes it's propably using TThread anyway...<br>
>><br>
> Because Foreground code (here the calls made by the "visible" code the user creates to use "TParallel") and the "background code" in the threads that TParallel might create,  communicate (i.e. the Thread notifying the foreground code about a state such as "ready") via the Event-Queue and for this the foreground code need to call CheckSynchronize().<br>
><br>
> But CheckSynchronize() needs to be "manually" done by the user in a pure FPC project. Only with projects using the LCL (or mse-gui or whatever framework), this is done  without the user explicitly creating code for this.<br>
><br>
> How else should "SW.Stop;" in the example work ?<br>
><br>
> OK, "TStopWatch.Stop;" might call CheckSynchronize() in a loop with a timeout definable as a property of TStopWatch. This hopefully will not interfere with other CheckSynchronize() calls done e.g. by the LCL.<br>
></p>
<p>You do know that there exist other synchronisation primitives beside the event queue? And since the TParallel.For itself is a blocking call I highly suspect that they *don't* use the event queue, but TEvent and similar instead.</p>
<p>Regards,<br>
Sven</p>