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
>> [email protected]
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> --
> Serge Lages
> http://www.tharsis-software.com
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
