Hi WanMil, the loop in main (performance branch) does not always end, sometimes the main thread hangs in cmplService.take(); I guess this happens when the last preparer finishes after the test of getActiveCount() and before take() is called: do { try { cmplService.take(); } catch (InterruptedException exp) { System.err.println(exp.getMessage()); } } while (((ThreadPoolExecutor) threadPool).getActiveCount() > 0); The attached patch solves this problem. Gerd http://gis.19327.n5.nabble.com/file/n5533662/spuriois_hang.patch spuriois_hang.patch -- View this message in context: http://gis.19327.n5.nabble.com/Patch-Spurious-dead-main-thread-tp5533662p553... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, thanks for the patch. The problem is the getActiveCount() method. The javadoc tells that it returns the approximate number of active threads. The only chance that the old code dead locks is that getActiveCount() returns 1 but all threads have already been finished and all results have been taken via the completion service. The patch fixes one problem (so I committed it) but as long as we cannot guarantee that getActiveCount() returns the correct number of remaining threads I expect that we might face a problem the other way round: One or more jobs have not been completely finished but the loop exits because getActiveCount() returns 0 (which is *approximately* correct...). So I have to change that once more. WanMil
Hi WanMil,
the loop in main (performance branch) does not always end, sometimes the main thread hangs in cmplService.take(); I guess this happens when the last preparer finishes after the test of getActiveCount() and before take() is called:
do { try { cmplService.take(); } catch (InterruptedException exp) { System.err.println(exp.getMessage()); } } while (((ThreadPoolExecutor) threadPool).getActiveCount()> 0);
The attached patch solves this problem.
Gerd http://gis.19327.n5.nabble.com/file/n5533662/spuriois_hang.patch spuriois_hang.patch
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-Spurious-dead-main-thread-tp5533662p553... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I did never hit the problem that you describe. I don't think that this is meant with *approximately* correct result. I think the documentation just means that the calculation of the value happens at time x and the value is returned *somewhat* later without blocking all other activities. So, between x and *somewhat* later the thread might have finished. On the other hand, we ask for the value and evaluate the loop condition before calling take() again. I think this is another *somewhat* later. Gerd WanMil wrote
Hi Gerd,
thanks for the patch. The problem is the getActiveCount() method. The javadoc tells that it returns the approximate number of active threads. The only chance that the old code dead locks is that getActiveCount() returns 1 but all threads have already been finished and all results have been taken via the completion service. The patch fixes one problem (so I committed it) but as long as we cannot guarantee that getActiveCount() returns the correct number of remaining threads I expect that we might face a problem the other way round: One or more jobs have not been completely finished but the loop exits because getActiveCount() returns 0 (which is *approximately* correct...).
So I have to change that once more.
WanMil
Hi WanMil,
the loop in main (performance branch) does not always end, sometimes the main thread hangs in cmplService.take(); I guess this happens when the last preparer finishes after the test of getActiveCount() and before take() is called:
do { try { cmplService.take(); } catch (InterruptedException exp) { System.err.println(exp.getMessage()); } } while (((ThreadPoolExecutor) threadPool).getActiveCount()> 0);
The attached patch solves this problem.
Gerd http://gis.19327.n5.nabble.com/file/n5533662/spuriois_hang.patch spuriois_hang.patch
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-Spurious-dead-main-thread-tp5533662p553... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-Spurious-dead-main-thread-tp5533662p553... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (2)
-
GerdP -
WanMil