Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Robert, Currently building the SVN trunk and I get this warning : 1D:\OpenSceneGraph\include\osgDB/DatabasePager(348) : warning C4099: 'osgDB::DatabasePager::RequestQueue' : type name first seen using 'class' now seen using 'struct' 1D:\OpenSceneGraph\include\osgDB/DatabasePager(312) : see declaration of 'osgDB::DatabasePager::RequestQueue' I'll let you know if everything works fine when the build will finish. On Sun, Jun 15, 2008 at 7:58 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello Robbert, The SVN version is missing the changes (ReadQueue definition) to the Databasepager header file. -- Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: zondag 15 juni 2008 18:03 To: OpenSceneGraph Users Subject: Re: [osg-users] New Improved DatabasePager,now with even more threading! Please take a taste today :-) Hi Guys, While away on training last week, we came across the Windows debug build reporting problem in std::sort and find calls, and investigations into the issue suggested that it was down to the cull thread modifying the DatabaseRequest fields at the same time that those same fields were being used inside the std algorithms being run by the DatabasePager threads. The worst thing that would actually happen is that very occassionally the list would be sorted into incorrect order, but this in itself would only lead to a slightly sub-optimial ordering of loading tiles, it shouldn't actually break any app - so it's really more of an issue with the debugger being overly strict rather than having a serious race condition that would cause real problems. However, even having a benign, occasional, slightly sub-optimal ordering is a problem if end users under Windows are going to keep stumbling over this issue to due to compiler debugging screaming that there is a serious problem and crashing - so it's a community support problem rather than actual a real problem for proper applications, but having more support than we already have is an issue so I've gone ahead and found a solution. Now checked into SVN is an addition of a mutex lock on the current queue that a DatabaseRequest is a member inside the code that updates the DatabaseRequest parameters. This fix should prevent the problems appearing under VisualStudio debug build, it alas will also mean that all users will have to pay the cost of an non essential mutex lock. Could you guys do an svn update and let me know how things go. Robert. On Fri, Jun 13, 2008 at 10:48 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi James, I tried to look to this problem but can't find anything, moreover it seems to work without problems in release (I'll try to make some stress tests soon to be sure). On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James [EMAIL PROTECTED] wrote: I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Sun, Jun 15, 2008 at 6:58 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello Robbert, The SVN version is missing the changes (ReadQueue definition) to the Databasepager header file. How many times do will I have to type this same message now fixed:) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
No more crash in debug ! :) Good work ! On Mon, Jun 16, 2008 at 11:18 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi Robert, Currently building the SVN trunk and I get this warning : 1D:\OpenSceneGraph\include\osgDB/DatabasePager(348) : warning C4099: 'osgDB::DatabasePager::RequestQueue' : type name first seen using 'class' now seen using 'struct' 1D:\OpenSceneGraph\include\osgDB/DatabasePager(312) : see declaration of 'osgDB::DatabasePager::RequestQueue' I'll let you know if everything works fine when the build will finish. On Sun, Jun 15, 2008 at 7:58 PM, Smeenk, R.J.M. (Roland) [EMAIL PROTECTED] wrote: Hello Robbert, The SVN version is missing the changes (ReadQueue definition) to the Databasepager header file. -- Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: zondag 15 juni 2008 18:03 To: OpenSceneGraph Users Subject: Re: [osg-users] New Improved DatabasePager,now with even more threading! Please take a taste today :-) Hi Guys, While away on training last week, we came across the Windows debug build reporting problem in std::sort and find calls, and investigations into the issue suggested that it was down to the cull thread modifying the DatabaseRequest fields at the same time that those same fields were being used inside the std algorithms being run by the DatabasePager threads. The worst thing that would actually happen is that very occassionally the list would be sorted into incorrect order, but this in itself would only lead to a slightly sub-optimial ordering of loading tiles, it shouldn't actually break any app - so it's really more of an issue with the debugger being overly strict rather than having a serious race condition that would cause real problems. However, even having a benign, occasional, slightly sub-optimal ordering is a problem if end users under Windows are going to keep stumbling over this issue to due to compiler debugging screaming that there is a serious problem and crashing - so it's a community support problem rather than actual a real problem for proper applications, but having more support than we already have is an issue so I've gone ahead and found a solution. Now checked into SVN is an addition of a mutex lock on the current queue that a DatabaseRequest is a member inside the code that updates the DatabaseRequest parameters. This fix should prevent the problems appearing under VisualStudio debug build, it alas will also mean that all users will have to pay the cost of an non essential mutex lock. Could you guys do an svn update and let me know how things go. Robert. On Fri, Jun 13, 2008 at 10:48 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi James, I tried to look to this problem but can't find anything, moreover it seems to work without problems in release (I'll try to make some stress tests soon to be sure). On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James [EMAIL PROTECTED] wrote: I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Guys, While away on training last week, we came across the Windows debug build reporting problem in std::sort and find calls, and investigations into the issue suggested that it was down to the cull thread modifying the DatabaseRequest fields at the same time that those same fields were being used inside the std algorithms being run by the DatabasePager threads. The worst thing that would actually happen is that very occassionally the list would be sorted into incorrect order, but this in itself would only lead to a slightly sub-optimial ordering of loading tiles, it shouldn't actually break any app - so it's really more of an issue with the debugger being overly strict rather than having a serious race condition that would cause real problems. However, even having a benign, occasional, slightly sub-optimal ordering is a problem if end users under Windows are going to keep stumbling over this issue to due to compiler debugging screaming that there is a serious problem and crashing - so it's a community support problem rather than actual a real problem for proper applications, but having more support than we already have is an issue so I've gone ahead and found a solution. Now checked into SVN is an addition of a mutex lock on the current queue that a DatabaseRequest is a member inside the code that updates the DatabaseRequest parameters. This fix should prevent the problems appearing under VisualStudio debug build, it alas will also mean that all users will have to pay the cost of an non essential mutex lock. Could you guys do an svn update and let me know how things go. Robert. On Fri, Jun 13, 2008 at 10:48 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi James, I tried to look to this problem but can't find anything, moreover it seems to work without problems in release (I'll try to make some stress tests soon to be sure). On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James [EMAIL PROTECTED] wrote: I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester.org/listinfo.cgi/osg-users-openscenegraph.org The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hello Robbert, The SVN version is missing the changes (ReadQueue definition) to the Databasepager header file. -- Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: zondag 15 juni 2008 18:03 To: OpenSceneGraph Users Subject: Re: [osg-users] New Improved DatabasePager,now with even more threading! Please take a taste today :-) Hi Guys, While away on training last week, we came across the Windows debug build reporting problem in std::sort and find calls, and investigations into the issue suggested that it was down to the cull thread modifying the DatabaseRequest fields at the same time that those same fields were being used inside the std algorithms being run by the DatabasePager threads. The worst thing that would actually happen is that very occassionally the list would be sorted into incorrect order, but this in itself would only lead to a slightly sub-optimial ordering of loading tiles, it shouldn't actually break any app - so it's really more of an issue with the debugger being overly strict rather than having a serious race condition that would cause real problems. However, even having a benign, occasional, slightly sub-optimal ordering is a problem if end users under Windows are going to keep stumbling over this issue to due to compiler debugging screaming that there is a serious problem and crashing - so it's a community support problem rather than actual a real problem for proper applications, but having more support than we already have is an issue so I've gone ahead and found a solution. Now checked into SVN is an addition of a mutex lock on the current queue that a DatabaseRequest is a member inside the code that updates the DatabaseRequest parameters. This fix should prevent the problems appearing under VisualStudio debug build, it alas will also mean that all users will have to pay the cost of an non essential mutex lock. Could you guys do an svn update and let me know how things go. Robert. On Fri, Jun 13, 2008 at 10:48 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi James, I tried to look to this problem but can't find anything, moreover it seems to work without problems in release (I'll try to make some stress tests soon to be sure). On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James [EMAIL PROTECTED] wrote: I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester.org/listinfo.cgi/osg-users-openscenegraph.org The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi James, I tried to look to this problem but can't find anything, moreover it seems to work without problems in release (I'll try to make some stress tests soon to be sure). On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James [EMAIL PROTECTED] wrote: I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester.org/listinfo.cgi/osg-users-openscenegraph.org The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
I'm having a similar issue with DatabasePager::RequestQueue::takeFirst() (osg trunk, Debug build, windows XP VS2005). I'm getting some assertion errors at _requestList.sort (sequence not ordered). Even after adding the updateBlock(). I'm pretty new to this code section, so I'm probably off base here: Is it possible that the state of the databaseRequest objects within the list are being updated (from other threads) during the sort? IE. If the _timestampLastRequest or _priorityLastRequest are changing during the sort, the sort could become unstable. ___ Jim Lynch -Original Message- On Tue, May 27, 2008 at 12:08 PM, Tim Moore timoore at redhat.com wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester.org/listinfo.cgi/osg-users-openscenegraph.org The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Tue, May 27, 2008 at 12:08 PM, Tim Moore [EMAIL PROTECTED] wrote: Indeed. I've made the necessary changes to FlightGear, and it seems to be working fine. Except for being a cpu hog. Apparently, the pager thread is not blocked properly and continuously spins. The fact that the queue is empty is confirmed by the debug messages printed after the block call: HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0 I have been trying to find the place where the blocking is re-established when the queue goes empty, but could not find it. So I added an updateBlock() call at the end of DatabasePager::RequestQueue::takeFirst that seems to fix the issue. Could have added the call within the if-block, but this has the additional benefit of stopping runaway loops should somehow the pager thread get woken up without work to do. Index: DatabasePager.cpp === --- DatabasePager.cpp (revision 8398) +++ DatabasePager.cpp (working copy) @@ -273,6 +273,7 @@ databaseRequest = _requestList.front(); _requestList.erase(_requestList.begin()); } +updateBlock(); } I am not sure if I need an osg-submissions mail for this? -- Cheers, Csaba/Jester ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Tue, Jun 3, 2008 at 4:48 PM, Robert Osfield [EMAIL PROTECTED] wrote: Could you do an svn update on the OSG and let know if things are no work fine at your end, It works, thanks. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Csaba,
Thanks for spotting the missing updateBlock(). I've now added this
and checked it in. I put the updateBlock() inside the if () {} code
block, but other than that is identical to your own change.
Must admit I hadn't spotted the problem, the downside of having a four
core machine...
Could you do an svn update on the OSG and let know if things are no
work fine at your end,
Cheers,
Robert.
On Tue, Jun 3, 2008 at 3:14 PM, Csaba Halász [EMAIL PROTECTED] wrote:
On Tue, May 27, 2008 at 12:08 PM, Tim Moore [EMAIL PROTECTED] wrote:
Indeed. I've made the necessary changes to FlightGear, and it seems to
be working fine.
Except for being a cpu hog.
Apparently, the pager thread is not blocked properly and continuously
spins. The fact that the queue is empty is confirmed by the debug
messages printed after the block call:
HANDLE_NON_HTTP 0: _pager-_requestList.size()= 0 to delete = 0
I have been trying to find the place where the blocking is
re-established when the queue goes empty, but could not find it. So I
added an updateBlock() call at the end of
DatabasePager::RequestQueue::takeFirst that seems to fix the issue.
Could have added the call within the if-block, but this has the
additional benefit of stopping runaway loops should somehow the pager
thread get woken up without work to do.
Index: DatabasePager.cpp
===
--- DatabasePager.cpp (revision 8398)
+++ DatabasePager.cpp (working copy)
@@ -273,6 +273,7 @@
databaseRequest = _requestList.front();
_requestList.erase(_requestList.begin());
}
+updateBlock();
}
I am not sure if I need an osg-submissions mail for this?
--
Cheers,
Csaba/Jester
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Serge, I test the new DatabasePager with a regular pagedLOD database. Like you : all seems to work fine in release mode but I have a crash in debug mode. I work with Visual studio 2005 under Windows 2000. Serge Lages a écrit : On Thu, May 22, 2008 at 5:22 PM, Robert Osfield [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I've reviewed all the places that read and write the RequestQueue::_requestList and they all look like they acquire the _requestMutex before they use the list. This leaves me a bit empty handed w.r.t what might be amiss with the debug execution. Anyone can test it with a regular database to be sure that it doesn't come from my custom PagedLOD ? I get this crash in debug mode under WinXP and Visual Studio 2005 Express. In release everything goes fine. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Lamoliatte Stephane RD Engineer R.S.A. Cosmos Z.I. de la Vaure - B.P.40 42290 Sorbiers, France Tél : +33 (0)4 77 53 30 48 Fax : +33 (0)4 77 53 38 61 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Fri, May 23, 2008 at 8:08 AM, Stephane Lamoliatte [EMAIL PROTECTED] wrote: Hi Serge, I test the new DatabasePager with a regular pagedLOD database. Like you : all seems to work fine in release mode but I have a crash in debug mode. I work with Visual studio 2005 under Windows 2000. Hi Stephane, Thanks for the confirmation, I'll try to investigate further today. It seems that even in release mode it's not stable, I got some weird crashes yesterday. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi, Robert Osfield wrote: Hi Serge, On Thu, May 22, 2008 at 3:30 PM, Robert Osfield [EMAIL PROTECTED] wrote: So there must be somewhere else that isn't playing ball properly and hasn't acquired the lock as it should. I've reviewed all the places that read and write the RequestQueue::_requestList and they all look like they acquire the _requestMutex before they use the list. are all the acquires from different threads? I have not checked lately, but there used to be a difference between Win/Lin wrt taking mutexes recursively. Win allowed recursive if the call was from within the same thread, Lin did not. jp This leaves me a bit empty handed w.r.t what might be amiss with the debug execution. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi, Robert Osfield wrote: Hi J.P, On Fri, May 23, 2008 at 9:16 AM, J.P. Delport [EMAIL PROTECTED] wrote: I've reviewed all the places that read and write the RequestQueue::_requestList and they all look like they acquire the _requestMutex before they use the list. are all the acquires from different threads? I have not checked lately, but there used to be a difference between Win/Lin wrt taking mutexes recursively. Win allowed recursive if the call was from within the same thread, Lin did not. I believe this is still true w.r.t Windows allowing recursive mutexes, while pthreads doesn't. However, I doubt this is relevant to the instability under Windows, as the code started out under Linux, if code was such that a single thread was entering the same mutex then Linux would just deadlock, unable to acquire the same mutex twice. I'm not getting deadlocks. Yes, you are right for the case where a lock is only released by the same thread that acquired it. This is the normal use case that e.g. scopedlock enforces. I have through undisciplined use of mutexes (not implying OSG does any of this :-) created cases where the Linux version just blocks (not deadlocks) and the Windows version runs right through. Perhaps one things that is being stressed more know is the general thread safety osgDB::Registry and the plugins, as the new DatabasePager allows multiple loads to be running in a parallel. Yes, I also wish there was an easy wrapper around OpenThreads to help one debug the multi-threaded execution. jp Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Robert, Yes, I also wish there was an easy wrapper around OpenThreads to help one debug the multi-threaded execution. What do you have in mind w.r.t an easy wrapper around OpenThreads? I was hoping for something like GLIntercept (that sits between the app and OpenGL and can trace all calls) for threads. Hopefully systemtap http://sourceware.org/systemtap/ would help one day. Debugging multi-threaded execution is certainly not easy so could do with tools to help you. Finding cross-platform tools would be even harder :( jp Robert. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi J.P, On Fri, May 23, 2008 at 9:53 AM, J.P. Delport [EMAIL PROTECTED] wrote: Yes, you are right for the case where a lock is only released by the same thread that acquired it. This is the normal use case that e.g. scopedlock enforces. Ahhh this is a different issue, as you say ScopedLock does enforce that a single thread does both the lock and unlock. The OpenThreads::ReentrantMutex is perhaps way more of these issue might arise, as it attempts to implement a mutex that can be called recusively, so in theory behaving the same between Window threads and pthreads. However, there have been instances where I've found problems in code rely on ReentrantMutex, alas I don't recall the details now. DatabasePager itself doesn't rely on an mutexes that need to recursive/reentrant, but some plugins have serialize code in them to prevent problems with multi-threading. Perhaps some plugins aren't yet thread safe, and don't have anything to serialized access to them... Yes, I also wish there was an easy wrapper around OpenThreads to help one debug the multi-threaded execution. What do you have in mind w.r.t an easy wrapper around OpenThreads? Debugging multi-threaded execution is certainly not easy so could do with tools to help you. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Fri, May 23, 2008 at 10:22 AM, Robert Osfield [EMAIL PROTECTED] wrote: One problem that I have observed steady growth in memory usage on a very large database I have. I don't know yet if this is a leak or a load balancing problem. I wouldn't expect this issue to be related to the instability under Windows though. There's no hight memory usage for me. I tried to investigate further on this problem but can't find anything. If I create only one thread in the pager it also crash. The bug always happens line 272, sometimes _requestList is empty, sometimes not (but it still crash)... -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Robert, All these things are good news ! :) I am currently building and I'll let you know how it works here (I have a custom PagedLOD which calls requestNodeFile). On Thu, May 22, 2008 at 12:09 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi All, Over the last week I've been working on improving the performance of the DatabasePager when paging data over http, and storing the tiles in a local file cache, I checked in the first cut of the work last night. Previous rev of the DatabasePager had only a single thread for reading tiles, and if one of these tiles was an http request it would stall the loading of all tiles behind it in the queue till the http read had completed, effectively stalls the paging - so you see a long hesitation before any new tiles are loaded in. This artefact is most obvious when you have lots of data already downloaded in your local file cache, so parts of your database loads in very quickly - almost instantly, but when a single tile has to be pulled in via http everything stalls, even if you move to an area where there is lots of data in the local file cache where no http requests are required nothing happens till the http request is complete, something that might take 5 to 10 seconds. All in all it leads rather unpleasant stop/start experience of your data - although I must add the note, its not the frame rate that stalls as you'll still get a solid 75Hz (or whatever vysnc is set to) but the stalls paging is what ruins things. My first take was to put threading into the curl plugin, with it multi-threading the http requests, this worked but... it was complicated to manage the dialog between the DatabasePager and the plugin, and it couldn't take advantage of the tile priority system that the pager has for making sure the most visually important tiles get loaded in, and the no longer visible ones get discarded. There was also problems with closing the threads and exit of the application. I did work around this via an explicit destruction of the osgDB::Registry and new ReaderWriter::stopThreading() method implemented by the curl plugin, but this still meant that all apps using http paging would have to add this explicitly destruction just to prevent crashes on exit. Sometimes you head off on a particular code route and few it getting more and more convoluted way beyond the actual complexity of the problem being tackled, and this was just one instance, when this happens you have to take a step back and realise that the solution to the problem is an inappropriate one, and that it's time to throw away the work and start afresh. So... on to the second take - to refactor the DatabasePager so that rather than have one thread, to have a list of threads, each with different responsibilities. Original DatabasePager subclassed from OpenThreads::Thread, so it was a case of is a thread, now DatabasePager doesn't subclass from OpenThreads::Thread at all, instead has a list of DatabaseThread objects, each of which subclasses from OpenThreads::Thread, so now we have DatabasePager has a list of threads. One of the rules of OO programming is 'prefer has a over is a ' so I guess we might be on the right track. The DatabasePager can now potentially be set up like: 1) A single DatabaseThread that handles all http and non http requests 2) A DatabaseThread for handling non http requests, and one DatabaseThread for handling http requests 3) Multiple DatabaseThread for each of non http and http requests I haven't just made this configurable, but it's my plan to provide public methods for configuring how many threads to allocate, first I need to decide on the least awkward API for it. One can toggle between the above right now by tweaking #if #endif blocks in the DatabasePager.cpp, and it's possible to run all of the three above, so I already know that all of the above work. For now option 2 is complied by default as this provides a reasonable balance of performance. Another change to the DatabasePager was to store the DatabaseRequest objects that are used internally by the pager directly on the ProxyNode/PagedLOD nodes as well as internally in the various queues in the DatabasePager. In the ProxyNode/PagedLOD classes you'll now see getDatabaseRequest method that returns an osg::ref_ptrosg::Referenced. This tweak makes it much quicker for the cull traversal to update the DatabaseRequests according to the needs for the new frame, and avoids the need to costly mutex locks and linear searches that was previously being done in the DatabasePager::requestNodeFile method. Previously the cost of the requestNodeFile could get rather high when lots of requests backed up - it was a O(n squared) cost that could accumulate high to 5+ms extra cull traveral time each frame, enough to break frame in some instances. The new code is O(n) as well as having much lower overhead per op, so now the cost in cull traversal rarely
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Thu, May 22, 2008 at 12:09 PM, Robert Osfield [EMAIL PROTECTED] wrote: Another change to the DatabasePager was to store the DatabaseRequest objects that are used internally by the pager directly on the ProxyNode/PagedLOD nodes as well as internally in the various queues in the DatabasePager. In the ProxyNode/PagedLOD classes you'll now see getDatabaseRequest method that returns an osg::ref_ptrosg::Referenced. This tweak makes it much quicker for the cull traversal to update the DatabaseRequests according to the needs for the new frame, and avoids the need to costly mutex locks and linear searches that was previously being done in the DatabasePager::requestNodeFile method. Hum... Should it be possible to make the PagedLOD getDatabaseRequest method virtual ? :) -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Serge, On Thu, May 22, 2008 at 1:42 PM, Serge Lages [EMAIL PROTECTED] wrote: Hum... Should it be possible to make the PagedLOD getDatabaseRequest method virtual ? :) This would possible. It is however, something that is meant to be maintained by the DatabasePager directly, and all it needs for these is a reference to ref_ptr that PagedLOD stores on it behalf. I can only envisage a need to make this virtue in cases where you customize the data storage itself. Could you explain your needs for making this virtue? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Thu, May 22, 2008 at 2:47 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Serge, On Thu, May 22, 2008 at 1:42 PM, Serge Lages [EMAIL PROTECTED] wrote: Hum... Should it be possible to make the PagedLOD getDatabaseRequest method virtual ? :) This would possible. It is however, something that is meant to be maintained by the DatabasePager directly, and all it needs for these is a reference to ref_ptr that PagedLOD stores on it behalf. I can only envisage a need to make this virtue in cases where you customize the data storage itself. Could you explain your needs for making this virtue? I customize the data storage. :) My PagedLOD is really particular because it doesn't store directly nodes, but layers (we have the texture, the terrain and the data on top of the terrain in different layers) and our PagedLOD recover everything and put it together. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Serge, On Thu, May 22, 2008 at 1:57 PM, Serge Lages [EMAIL PROTECTED] wrote: I customize the data storage. :) My PagedLOD is really particular because it doesn't store directly nodes, but layers (we have the texture, the terrain and the data on top of the terrain in different layers) and our PagedLOD recover everything and put it together. Would it be possible to see the implementation? i..e the headers and source files for your custom PagedLOD. W.r.t data assembly I'd be inclined to do this in a plugin, but then I know so little about the details of what you are doing I can't really provide any particular insights. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Serge, On Thu, May 22, 2008 at 2:11 PM, Robert Osfield [EMAIL PROTECTED] wrote: I customize the data storage. :) I now wonder if the PerRangeData shouldn't be a base class that you extend, if you derive from this then the various PagedLOD methods would still be available, so no need to go add virtual methods where none would otherwise be required. We'd need to add other virtual methods to support make PerRangeData subclassable, and PerRangeDataList would have to be a list of ref_ptrPerRangeData but that is all doable... although perhaps a bit more intrusive w.r.t. backwards compatibility of the API. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Forget what I've said, I found a workaround.
My custom PagedLOD works juste fine with the new DatabasePager, but only
in release mode.
In debug, Visual Studio spot an error in :
DatabasePager.cpp line 272 :
if (!_requestList.empty())
{
_requestList.sort(SortFileRequestFunctor());
databaseRequest = _requestList.front();
_requestList.erase(_requestList.begin());
}
It crash because requestList is empty when we call databaseRequest =
_requestList.front();
So it seems to be a thread problem, is there anywhere requestList is
modified without locking _requestMutex ?
On Thu, May 22, 2008 at 3:42 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Serge,
On Thu, May 22, 2008 at 2:11 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
I customize the data storage. :)
I now wonder if the PerRangeData shouldn't be a base class that you
extend, if you derive from this then the various PagedLOD methods
would still be available, so no need to go add virtual methods where
none would otherwise be required.
We'd need to add other virtual methods to support make PerRangeData
subclassable, and PerRangeDataList would have to be a list of
ref_ptrPerRangeData but that is all doable... although perhaps a
bit more intrusive w.r.t. backwards compatibility of the API.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Serge,
Curious. The particular bit of code does actually acquire the mutex
lock - the whole method is:
void DatabasePager::RequestQueue::takeFirst(osg::ref_ptrDatabaseRequest
databaseRequest)
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(_requestMutex);
if (!_requestList.empty())
{
_requestList.sort(SortFileRequestFunctor());
databaseRequest = _requestList.front();
_requestList.erase(_requestList.begin());
}
}
So there must be somewhere else that isn't playing ball properly and
hasn't acquired the lock as it should.
Robert.
On Thu, May 22, 2008 at 3:04 PM, Serge Lages [EMAIL PROTECTED] wrote:
Forget what I've said, I found a workaround.
My custom PagedLOD works juste fine with the new DatabasePager, but only
in release mode.
In debug, Visual Studio spot an error in :
DatabasePager.cpp line 272 :
if (!_requestList.empty())
{
_requestList.sort(SortFileRequestFunctor());
databaseRequest = _requestList.front();
_requestList.erase(_requestList.begin());
}
It crash because requestList is empty when we call databaseRequest =
_requestList.front();
So it seems to be a thread problem, is there anywhere requestList is
modified without locking _requestMutex ?
On Thu, May 22, 2008 at 3:42 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Serge,
On Thu, May 22, 2008 at 2:11 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
I customize the data storage. :)
I now wonder if the PerRangeData shouldn't be a base class that you
extend, if you derive from this then the various PagedLOD methods
would still be available, so no need to go add virtual methods where
none would otherwise be required.
We'd need to add other virtual methods to support make PerRangeData
subclassable, and PerRangeDataList would have to be a list of
ref_ptrPerRangeData but that is all doable... although perhaps a
bit more intrusive w.r.t. backwards compatibility of the API.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
Hi Serge, On Thu, May 22, 2008 at 3:30 PM, Robert Osfield [EMAIL PROTECTED] wrote: So there must be somewhere else that isn't playing ball properly and hasn't acquired the lock as it should. I've reviewed all the places that read and write the RequestQueue::_requestList and they all look like they acquire the _requestMutex before they use the list. This leaves me a bit empty handed w.r.t what might be amiss with the debug execution. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New Improved DatabasePager, now with even more threading! Please take a taste today :-)
On Thu, May 22, 2008 at 5:22 PM, Robert Osfield [EMAIL PROTECTED] wrote: I've reviewed all the places that read and write the RequestQueue::_requestList and they all look like they acquire the _requestMutex before they use the list. This leaves me a bit empty handed w.r.t what might be amiss with the debug execution. Anyone can test it with a regular database to be sure that it doesn't come from my custom PagedLOD ? I get this crash in debug mode under WinXP and Visual Studio 2005 Express. In release everything goes fine. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
