[fpc-devel] Suspicion about TThread.Synchronize

[Luca Olivetti]

El 4/2/18 a les 20:17, Sven Barth via fpc-devel ha escrit:

>> What happens if
>> - thread 1, has just finished the line
>> ThreadQueueAppend(AThread.FSynchronizeEntry);
>> - thread 2 now calls synchronize, and
>>     - as soon as thread1 leaves the CriticalSection in ThreadQueueAppend
>> => thread2 enters that CriticalSection
>> - thread2 adds it entry to the list, assigning it the Next^ of thread
>> 1's entry
>> - now thread1 continues, it sets Next^ to nil, removing the reference to
>> thread 2's entry.
>>
>> Thread 2 would no longer be in the list.
>> That also means, if thread 2's entry has a Next^, then this may not be
>> set to nil, if the entry it points to is removed?
> 
> The queue head is only modified inside ThreadQueueAppend() and
> PopThreadQueueHead() (well, and RemoveQueuedEvents()) of which all use
> the ThreadQueueLock while working on the queue. Once ThreadQueueAppend()
> inside Synchronize() is executed the event is already processed (because
> ThreadQueueAppend() is a blocking call in that case) and the work on
> AThread.FSynchronizeEntry is merely cleanup to avoid any misbehaviour
> (at that time the entry is already no longer part of the queue).

I still think there's something wrong with thread in fpc 3.0.4.

I usually suspect that the bugs are in my code, and that's usually the 
case ;-), but I have a program with several threads, calling 
synchronize, that has worked flawlessly 24/7 for 6 years.

Due to some modifications required by the customer, 9 months ago I 
compiled it with fpc 3.0.4 (lazarus 1.8.4). The customer complains that, 
from time to time, it stops working. The UI is still responsive, 
everything seems to work but one of the elements doesn't work.

By looking at the logs it seems that one of the threads stops running. I 
thought that maybe the problem was an unhandled exception somewhere 
inside the thread[*], so I wrapped the Execute loop in a try..except 
block. No luck, no exceptions logged but it still stops working from 
time to time.


[*] note that I have around 20 instances of that same thread code 
running in another program (fpc 2.6.4) with no problem whatsoever, so I 
doubt that's the case, but one never knows.

Debugging the program here, I see the thread is stopped inside a 
synchronize call that is never executed.

Btw: is there a way to find where a thread is stopped/waiting? it's been 
a pain to find it, I had to assign a field almost after every 
instruction to know where it stops, e.g.

      FWhereAmI:=1;
      DoThis;
      FWhereAmI:=2;
      DoThat;
      FWhereAmi:=3;
      ....

so that, by putting a breakpoint in the main program when it checks if 
the thread has finished its job, I can examine the thread and see the 
value of its FWhereAmI field.

Of course I cannot reproduce the issue with a simpler test program :-/

I guess is one more project I have to revert to fpc 2.6.4/lazarus 1.6.4 :-(

I forgot: this is with win32

Bye
-- 
Luca