Recent

Author Topic: [SOLVED] Thread Safety?  (Read 22290 times)

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Thread Safety?
« Reply #45 on: February 22, 2018, 04:31:51 pm »
@ASerge

Thanks. Works flawlessly in linux.

sam707

  • Guest
Re: Thread Safety?
« Reply #46 on: February 22, 2018, 07:10:15 pm »
switchThred I'm not sure but SpinWait has no effect on Windows platforms, as told on the wiki it depends upon platforms

so stiill prefer TThread.Queue with no 'sleep' needed, less lines to code and crosspatfArm
« Last Edit: February 22, 2018, 07:39:16 pm by sam707 »

ASerge

  • Hero Member
  • *****
  • Posts: 2212
Re: Thread Safety?
« Reply #47 on: February 22, 2018, 07:52:46 pm »
so stiill prefer TThread.Queue with no 'sleep' needed, less lines to code and crosspatfArm
In my example, this means 200,000 times using Queue. And all this is still executed in the main stream. No, I do not like it.

rvk

  • Hero Member
  • *****
  • Posts: 6056
Re: Thread Safety?
« Reply #48 on: February 22, 2018, 07:58:17 pm »
so stiill prefer TThread.Queue with no 'sleep' needed, less lines to code and crosspatfArm
In my example, this means 200,000 times using Queue. And all this is still executed in the main stream. No, I do not like it.
True, but you could also only execute it every 500th iteration. Or have a counter for time and do it every 0,5 second. In that case the thread dictates how many updates there are. But there is something to say for letting the main-thread do this itself. Both are viable options and probably dependent on the circumstances.


zoltanleo

  • Sr. Member
  • ****
  • Posts: 486
Re: Thread Safety?
« Reply #49 on: February 22, 2018, 09:28:38 pm »
Please check in Linux
If it isn't difficult for you, attach a demo project to the message, please (use menu Project --> Publish Project ...)
Win10 LTSC x64/Deb 11 amd64(gtk2/qt5)/Darwin Cocoa (Monterey):
Lazarus x32/x64 2.3(trunk); FPC 3.3.1 (trunk), FireBird 3.0.10; IBX by TonyW

Sorry for my bad English, I'm using translator ;)

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Re: Thread Safety?
« Reply #50 on: February 22, 2018, 10:04:40 pm »
True, but you could also only execute it every 500th iteration. Or have a counter for time and do it every 0,5 second. In that case the thread dictates how many updates there are. But there is something to say for letting the main-thread do this itself. Both are viable options and probably dependent on the circumstances.
Since when is timing (or time)  a valid option for any kind of parallel processing? Explain?

Dead giveaway is that proper parallel processing is independent of time. I can give proof in pascal if you want... but it is rather basic....
Don't teach people to use a kludge when it should never, ever be necessary.
« Last Edit: February 22, 2018, 10:09:12 pm by Thaddy »
Specialize a type, not a var.

rvk

  • Hero Member
  • *****
  • Posts: 6056
Re: Thread Safety?
« Reply #51 on: February 22, 2018, 10:16:59 pm »
Since when is timing (or time)  a valid option for any kind of parallel processing? Explain?
When you want to inform another thread of your progress.

I'm sure, if you've done thread programming, you have also used Queue of Synchonize (or even PostMessage) from the thread itself, and not from a timer from the main-thread.

Also note that I said:
Quote
Both are viable options and probably dependent on the circumstances.

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Thread Safety?
« Reply #52 on: February 22, 2018, 10:25:33 pm »
True, but you could also only execute it every 500th iteration. Or have a counter for time and do it every 0,5 second. In that case the thread dictates how many updates there are. But there is something to say for letting the main-thread do this itself. Both are viable options and probably dependent on the circumstances.
Since when is timing (or time)  a valid option for any kind of parallel processing? Explain?
no one talks about processing only about progress reporting.

Dead giveaway is that proper parallel processing is independent of time. I can give proof in pascal if you want... but it is rather basic....
that's one way of looking at it. Yes I'd love to see a sample.
Don't teach people to use a kludge when it should never, ever be necessary.
well kludge is the only way to drive a stick, some might even argue that there is no need to it, hell in a decade some might argue there is no need for a driver either, to each its own.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

ASerge

  • Hero Member
  • *****
  • Posts: 2212
Re: Thread Safety?
« Reply #53 on: February 22, 2018, 10:28:54 pm »
If it isn't difficult for you, attach a demo project to the message, please (use menu Project --> Publish Project ...)
I found another mistake. If after the application is launched quickly terminates it, then there are different errors. When debugging, it shows the invalid states in the global Screen object. But if you wait one second, then everything works out. While I did not understand why, but it is easily solved by adding "OnTerminate: = nil" to the OnDestroy handler.

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Thread Safety?
« Reply #54 on: February 23, 2018, 04:28:59 am »
@ASerge, if you choose to set FThread.FreeOnTerminate := True then consider FThread = nil when you start the thread.

In the case of your project the thread was already started. So this code could possibly (while not probable) fail:
Code: Pascal  [Select][+][-]
  1.   FThread.FreeOnTerminate := True;
  2.   FThread.OnTerminate := @ThreadTerminated;  //<---- May fail

Worse in the form destruction event:
Code: Pascal  [Select][+][-]
  1. procedure TForm1.FormDestroy(Sender: TObject);
  2. begin
  3.   if Assigned(FThread) then
  4.     FThread.OnTerminate := nil;  //<--- May fail
  5.   FThread.Free;  //<--- May fail
  6. end;

There is no guaranty that before assigning nil to OnTerminate that the thread had not destroyed itself (due to FreeOnTerminate = True)
« Last Edit: February 23, 2018, 04:40:04 am by engkin »

kapibara

  • Hero Member
  • *****
  • Posts: 610
Re: Thread Safety?
« Reply #55 on: February 23, 2018, 05:00:17 am »
ASerges attached demo ran fine under Linux.
Lazarus trunk / fpc 3.2.2 / Kubuntu 22.04 - 64 bit

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Thread Safety?
« Reply #56 on: February 23, 2018, 05:02:20 am »
ASerges attached demo ran fine under Linux.

Did you delete your previous post?

kapibara

  • Hero Member
  • *****
  • Posts: 610
Re: Thread Safety?
« Reply #57 on: February 23, 2018, 05:44:17 am »
ASerge uploaded a working demo so I thought why keep mine. But if you want, I can attach it again.  ::)

Did you delete your previous post?
« Last Edit: February 23, 2018, 05:47:34 am by kapibara »
Lazarus trunk / fpc 3.2.2 / Kubuntu 22.04 - 64 bit

ASerge

  • Hero Member
  • *****
  • Posts: 2212
Re: Thread Safety?
« Reply #58 on: February 23, 2018, 12:43:12 pm »
@ASerge, if you choose to set FThread.FreeOnTerminate := True then consider FThread = nil when you start the thread.

In the case of your project the thread was already started. So this code could possibly (while not probable) fail:
Code: Pascal  [Select][+][-]
  1.   FThread.FreeOnTerminate := True;
  2.   FThread.OnTerminate := @ThreadTerminated;  //<---- May fail

Worse in the form destruction event:
Code: Pascal  [Select][+][-]
  1. procedure TForm1.FormDestroy(Sender: TObject);
  2. begin
  3.   if Assigned(FThread) then
  4.     FThread.OnTerminate := nil;  //<--- May fail
  5.   FThread.Free;  //<--- May fail
  6. end;

There is no guaranty that before assigning nil to OnTerminate that the thread had not destroyed itself (due to FreeOnTerminate = True)
In the first case, can be, but it is almost impossible that the thread ends between two assignment operations.
In the second case, everything is correct, because the thread does not freed until it calls OnTermnate in the main thread, but the main thread is busy doing these operations

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Re: Thread Safety?
« Reply #59 on: February 23, 2018, 01:07:05 pm »
@ASerge
Quote
In the first case, can be, but it is almost impossible that the thread ends between two assignment operations.
That's a trap and you just fell into it: pipe lining/branch prediction/out of order executiion.
Use an atomic operation for the assignments and you are safe.. And that is actually quite easy using the InterlockedExchange(Ptr) family.

Basically the same lack of theory that causes you to use instead of ignore timing.
Your reasoning is " Hey, I know it can fail, but just ignore it: it almost never happens....." which makes your code extremely hard to debug when it fails. Don't do it.
On modern CPU architectures it is even likely to fail because of branching: using threads  like that may lead to a stall - on one of the pipe lines - in which case....???
Rest of your code is quite neat.
« Last Edit: February 23, 2018, 01:25:23 pm by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018