tag:blogger.com,1999:blog-2428374771421713311.post5168508307887422612..comments2024-03-10T12:04:17.661-07:00Comments on The Oracle at Delphi: Spot the deadlockAnonymoushttp://www.blogger.com/profile/10119008505905401707noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-2428374771421713311.post-66257074518899922942007-10-07T18:21:58.000-07:002007-10-07T18:21:58.000-07:00Thanks a lot Allen for your posts from Kona. They ...Thanks a lot Allen for your posts from Kona. They were very, very instructive. Once again, it was proved, imho, that a community driven development is the path to follow. Now I remember a post in .non-tech newsgroup (with title “Top 3 requests” IIRC), in which someone asked for thread-safe VCL (ie. a very daunting task, imho). Nick responded “We’re very interested in that” – response which triggered an avalanche of posts from which the conclusion was that isn’t needed to have a thread-safe VCL but rather a easy, flexible way of sync/async signaling/messaging/passing data between threads and only the main thread to have the UI message loop, ie. no forms, panels, group boxes aso. in 2ndary threads, even it would be nice. IOW, a very “doable” task, even in Tiburon time frame. It was an impressive example of how community reacts, simplifies, and gives the right focus which is needed today for any IT company, imho.<br><br>On the technical side of things, “where is the code?” (TM) Can you post the new source in CC?m. Th.noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-10864160141048330092007-10-19T02:40:17.000-07:002007-10-19T02:40:17.000-07:00Chee Wee, So tell me *why* calling QueueIOWorkIte...Chee Wee,<br><br> So tell me *why* calling QueueIOWorkItem resolves it? I have my doubts that that actually resolves the problem.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-13019023540412931252007-10-19T02:03:56.000-07:002007-10-19T02:03:56.000-07:00Calling QueueIOWorkItem appears to resolve your is...Calling QueueIOWorkItem appears to resolve your issue. I've experimented several times, and found no deadlocks. <br><br>QueueWorkItem, performed the same number of times, seems to run into deadlocks more often.<br><br>These tests are performed while within the IDE and stepping through the program, and may not be conclusive though.Chee Wee Chuahttp://blogs.codegear.com/chewynoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-18916526138552983962007-10-19T01:14:30.000-07:002007-10-19T01:14:30.000-07:00Chee Wee, That's it. I was trying to highlig...Chee Wee,<br><br> That's it. I was trying to highlight that making a "thread-safe" VCL is not something easily done nor desirable in all cases.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-49013278070121690522007-10-08T17:08:22.000-07:002007-10-08T17:08:22.000-07:00...while waiting for your code, some more things t......while waiting for your code, some more things to note:<br><br>- Another multithreading scenario it would be a ThreadedDataModule. Yes, I know that nowadays we can create & use a TDataModule in a thread, but what I mean is to have a TDataModule assigned to a thread in a Delphi manner, ie. Bind the UI elements (“data aware controls”) to the data sources from the thread, connect to database, fetch the data, call the methods of the threaded datasets and the UI will respond etc. All these things would happen at different moments in time, at programmer's will. (ie. something like <br><br>TMainForm.OnButtonClick(Sender);<br>begin<br>with MyThreadedDataModule.SQLTable1 do<br>begin<br> SQL.Text:='SELECT * FROM T1 WHERE '+cMyNewFilter;<br> Open; //here the UI will be updated acordingly<br>end;<br><br>end;<br>- Do you are aware of very interesting things at<br>http://www.bluebytesoftware.com/blog/CategoryView,category,Technology.aspx<br><br>especially at<br><br>http://www.bluebytesoftware.com/blog/2007/04/19/MichaelSuesssParallelProgrammingInterviews.aspx<br><br>and, of course, at<br><br>http://www.thinkingparallel.com/<br><br><br>hthm. Th.noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-72138019060076839062007-10-17T12:24:26.000-07:002007-10-17T12:24:26.000-07:00Anyway, what is eventually painted on the screen c...Anyway, what is eventually painted on the screen comes from a data structure.<br><br>So, any access to a data structure must be serialized, and the serialization of the data structure for the screen occurs only in an IO thread.<br><br>If disorderly access to the screen's data structure occurs, what happens is usually data corruption. The OS might not react kindly to that.Chee Wee Chuahttp://blogs.codegear.com/chewynoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-38685740882708483962007-10-18T07:12:59.000-07:002007-10-18T07:12:59.000-07:00Okay...In that case, isn't locking the canvas ...Okay...<br><br>In that case, isn't locking the canvas unnecessary?Chee Wee Chuahttp://blogs.codegear.com/chewynoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-79867763710060142432007-10-17T08:53:44.000-07:002007-10-17T08:53:44.000-07:00Your code will eventually call QueueWorkItem(Sende...Your code will eventually call QueueWorkItem(Sender, WorkerEvent, WT_EXECUTEDEFAULT) and the WT_EXECUTEDEFAULT flag tells QueueWorkItem and hence QueueUserWorkItem will execute PaintLines and hence PaintLine in a non IO thread.<br><br>If too many non IO threads attempt to update the screen while an IO thread is updating a screen, a deadlock will occur.<br><br>Besides, non IO threads are not supposed to update the screen.Chee Wee Chuahttp://blogs.codegear.com/chewynoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-25084200288145413082007-10-18T02:25:47.000-07:002007-10-18T02:25:47.000-07:00Chee Wee, The deadlock is not in the PaintLines c...Chee Wee,<br><br> The deadlock is not in the PaintLines call. It is perfectly fine to paint to the screen from a background thread.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-47790624305006561632007-10-18T07:24:35.000-07:002007-10-18T07:24:35.000-07:00I don't see any SendMessage call in your code,...I don't see any SendMessage call in your code, directly or indirectly.<br><br>Is the exact code at: http://cc.codegear.com/Download.aspx?ID=25023 what you're talking about?Chee Wee Chuahttp://blogs.codegear.com/chewynoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-42837633547011630492007-10-18T07:36:23.000-07:002007-10-18T07:36:23.000-07:00Now that I've sit myself down, examining the c...Now that I've sit myself down, examining the code by running it, instead of calculating the issues through my head, I see where your SendMessage call is. It's in the code within FForm.ListBox1.Items.Add.<br><br>If SendMessage blocks, your app will be in a deadlock, isn't it?Chee Wee Chuahttp://blogs.codegear.com/chewynoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-76745876433791951922007-11-12T13:28:09.000-08:002007-11-12T13:28:09.000-08:00My goodness! you've been busy Allen!I'll ...My goodness! you've been busy Allen!<br><br>I'll have to take a moment to catch up on all your posts since September.Dennis Landihttp://pluginmgr.dennislandi.com/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-10672732819962742222008-04-03T00:19:39.000-07:002008-04-03T00:19:39.000-07:00Coincidentally I have recently written a threading...Coincidentally I have recently written a threading library for our projects here. I have an inter-process and inter-thread waitable queue, message posting and synchronous waits (e.g. a synch. wait where ProcessMessages is called when in the main thread, or a thread's message queue is pumped while in a thread). I am not using the APC functions yet - was thinking of looking into that.David Robbhttp://www.gatewayticketing.comnoreply@blogger.com