[SOLVED] TThread.WaitFor locks forever lazarus / 66-Unix ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2023-09-04 01:35 Hey Y'all, NOTE: Putting this here since I was only able to test this on Linux(Ubuntu 23.04 64b). I'm exploring all the possibilities of threads since I have a project that will heavily rely on them. In order to do that I've been following the Multithreaded Application Tutorial entry on the wiki. One of the See Also links mentioned is the Manager Worker Threads System. I downloaded the archived files from Source Forge: Manager Worker Thread Example. Attached is the same example with some alterations: Added an event to log stuff on the main forms ( Not using it since I needed to use WriteLn to debug the Destroy parts )Corrected a small bug that would only add one worker thread to the pool. Now, here's the problem:   When the application ends, it tries to Terminate->WaitFor->FreeAndNil each of the created worker threads.   That's expected and it should be ok for all the created threads!! ( In the example I use a queue of 3 ) But in my Linux environment, it will do that for Worker 0, but then it will get stuck on the WaitFor of Worker 1 forever. Since all 3 workers are created equal and they don't differ in anything obvious that I can see, I'm completely baffled and in need of help from the community!! Many thanks in advance!! Cheers, Gus ---------------------------------------------------------------------- 440bx · 2023-09-04 02:20 Just out of curiosity... is the code supposed to work on Windows ? and if it is then have you tried the code in Windows ?  if yes, does the problem show up there too ? ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2023-09-04 02:29 Hey 440bx, Quote from: 440bx on September 04, 2023, 04:20:15 amJust out of curiosity... is the code supposed to work on Windows ? I think, but I'm not quite sure, that the original coder did work in Windows, so I'm kinda assuming a YES here. Quote from: 440bx on September 04, 2023, 04:20:15 amand if it is then have you tried the code in Windows ?  The only way I can test under Windows is with wine. All my attempts doing so have resulted in the app claiming the error depicted on the attached image. I've done what I know to remove any files being loaded at start, but I've failed. Quote from: 440bx on September 04, 2023, 04:20:15 amif yes, does the problem show up there too ? As you can see by the above error in wine, I haven't been able to even get to the Close App part of the test Cheers, Gus ---------------------------------------------------------------------- sikale@aliyun.com · 2023-09-04 03:56 Unable to close in windows OS ---------------------------------------------------------------------- paweld · 2023-09-04 05:02 Remove SetSize(0) from CriticalSection (in procedureTManagerThread.Clear) because "GetNextItem" already blocks CS.  And why so many critical sections?    Tested on Windows 10 and Debian 11 ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2023-09-04 23:05 Hey paweld !! Quote from: paweld on September 04, 2023, 07:02:51 amRemove SetSize(0) from CriticalSection (in procedureTManagerThread.Clear) because "GetNextItem" already blocks CS.  This is awesome !!! SOOOO MANY THANKS !! I never suspected a deadlock and so I never went and find out Quote from: paweld on September 04, 2023, 07:02:51 amAnd why so many critical sections?  I asked myself the same question, but since the code is not mine and I dunno how to contact the author, I can't give you a good answer, sorry!!! Some of them kinda make sense when you're moving items from the Waiting to the Processing, And the Processing to the Finished. But with so many of them, one race condition would inevitably slip through!!   Quote from: paweld on September 04, 2023, 07:02:51 amTested on Windows 10 and Debian 11 Again, many, so many thanks for this!!! Cheers, Gus ---------------------------------------------------------------------- 440bx · 2023-09-04 23:30 Quote from: Gustavo 'Gus' Carreno on September 05, 2023, 01:05:43 amI never suspected a deadlock and so I never went and find out Just as a matter of course, when you have something that uses more than one (1) synchronization object, the possibility of a deadlock should always be a consideration. In this particular case, the last message is "waiting for worker 1" in spite of the fact that worker 1 has ended.  This strongly suggests that worker 1 ended without releasing a sync object. ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2023-09-05 18:12 Hey 440bx, Quote from: 440bx on September 05, 2023, 01:30:14 amQuote from: Gustavo 'Gus' Carreno on September 05, 2023, 01:05:43 amI never suspected a deadlock and so I never went and find out Just as a matter of course, when you have something that uses more than one (1) synchronization object, the possibility of a deadlock should always be a consideration. You're absolutely correct on this one!! When I saw that many CSs I asked the same question as @paweld, "Why so many?", and the next thing that came to mind was "This is probably cause some issues if not well managed". But then I completely forgot about it and just kinda panicked when the thing hung !! Quote from: 440bx on September 05, 2023, 01:30:14 amIn this particular case, the last message is "waiting for worker 1" in spite of the fact that worker 1 has ended.  This strongly suggests that worker 1 ended without releasing a sync object. From what @paweld mentioned on the above message, I think it's more of a re-entrant issue than something not releasing a CS. I haven't had the opportunity to read @paweld's corrected code. Cheers, Gus ---------------------------------------------------------------------- 440bx · 2023-09-05 18:34 Hi Gus, Quote from: Gustavo 'Gus' Carreno on September 05, 2023, 08:12:43 pmFrom what @paweld mentioned on the above message, I think it's more of a re-entrant issue than something not releasing a CS. That's possible too.  The last message displayed indicates there is, most likely, something "suspicious" going on with the sync objects.