Hi David, On Tue, Feb 2, 2010 at 6:56 PM, David Fries <[email protected]> wrote: > Not with the std::vector. It's modifying the request's data > values holding the wrong lock at times, but other than it being bad > behavior modifying data that isn't locked, it didn't seem to cause any > fatal errors. The requestNodeFile section only needed the queue to > get the lock, other than that it didn't use the queue.
OK. I'll keep pondering on this issue. I'm moving towards adding a mutex the DatabaseRequest/PagedLOD calling to prevent it's values being changed at the same time (by multiple cull threads). I'd include change the request queue it's assigned to under this mutex. > The std::multiset version requires it to remove and re-insert it from > and to the correct queue. It would do whatever > container.erase(container.end()) would do. The sorting would be > incorrect if it wasn't in the list and I had to fix the locking to > have the correct queue, I can't say I tried it without the assert > before fixing the problem. I can see how use of the multiset does raise the bar on making sure the correct queue is locked. My inclination is to adopt the multiset and come up with a scheme for modifying value in it in a robust and if possible easy to maintain way. Aside from the extra efficiency of multset implementation, there is still the far more serious of the shear numbers of DatabaseRequests that you can get into queues, it looks to me like many are being orphaned and not pruned from the queues when they go out of date promptly enough. In theory the DatabaseRequests that haven't been refreshed since the previous frame should be discarded from all the queues. There is a mechanism in place for this, but it clearly isn't working fully. It's this area that I'll be looking at this morning. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
