Threading problems

[LeP]

@vargatam77
It depends on your goals (or rather, the goals of the application), but there are also other methods that can be used to update a GUI.
For example, in your case, you could run your threads at maximum speed even without sleep, yield, or other events, storing the result(s) without updating the GUI directly.
The interface is updated from a timer event that accesses individual values ​​via properties of the individual threads.
You can program the timer with an interval of 100 ms or whatever works best for you.
This way, you can completely decouple the graphics part from the operational part.
This method is suitable if you need to display values ​​that change rapidly and are not interested in them on a timely basis.
In any case, the GUI is not directly subject to the control of Lazarus/FPC or your program, as it uses operating system objects/methods that in no way guarantee processing times.

[vargatam77]

Absolute nonsence.
Stick a sock in it or provide code. (you can't)

??? provide code of what? that js can do it? im not big on js but i have seen its queue processing events flawlessly, on the other hand I do know that VCL can do it. I just went back to BCB6 to rewrite the same code and it works flawless, because you know, windows threading do actually synchronise. I don't know why you have to get butthurt over it. And for this I can give you a code, though its the direct C++ copy of my initial code...

[vargatam77]

@vargatam77
It depends on your goals (or rather, the goals of the application), but there are also other methods that can be used to update a GUI.
For example, in your case, you could run your threads at maximum speed even without sleep, yield, or other events, storing the result(s) without updating the GUI directly.
The interface is updated from a timer event that accesses individual values ​​via properties of the individual threads.
You can program the timer with an interval of 100 ms or whatever works best for you.
This way, you can completely decouple the graphics part from the operational part.
This method is suitable if you need to display values ​​that change rapidly and are not interested in them on a timely basis.
In any case, the GUI is not directly subject to the control of Lazarus/FPC or your program, as it uses operating system objects/methods that in no way guarantee processing times.

yeah, thats a solid idea and I might just gonna do it, its jsut disappointing that such a simple thing has to be circumvented when the point of synchronise is exactly that it posts a message, waits for its processing and then returns to the calling thread. does not matter how long the LCL side processing takes. normally it would be the job of the thread queuing to process the incoming sync-s as they come in, but it clearly cant, unlike in VCL, where I can safely update the GUI from the thread sync calls. thats the entire point of these syncs, to make the communication between the threads and the main thread safe. the pupose will obviously not be to count from 0 to xymillion, i wanna query drivers, read config files and process their content etc, and some driver will answer slow, some will be fast and some will be immediate. ini processing again, some will take longer, some will be in human measures immediate, but it shouldnt matter for threading. thats why it exists. run all the processing parallel and get their outcome as they progress. anyway, thanks for the idea, as for such simplicity I dont want to write a complete processevent, i will probably just do as you have said and query thread variables from a timer

[vargatam77]

Hi
Use a MessageQueue for the comms...
Regards Benny

eta: If you need such a beast 
I have one in THIS Gitlab repo, it's located in the 'utils' directory... 

nice, but its total overkill for my simple little app appreaciate it though

[Thaddy]

nice, but its total overkill for my simple little app appreaciate it though

What overkill? You don't seem to appreciate that it is just as efficient as in other languages?