Hi Marcus,
Marcus Lindblom wrote:
>
> Yeah, I've implemented my own weak-ptr handling as well. It's not
> extensively used hence not very efficient/tested. (every refobject has a
> std::vector<weak_ptr> and on destruction, it sets the weak_ptrs to zero,
> which isn't very thread-safe. It's is efficient for weak_ptr lookup,
> since a valid weak_ptr is guaranteed to be correct. I have some control
> over ref-handling in my threads, so I can manage this currently.) You
> could do it with an external object that is ref-counted by weak_ptrs and
> the refobject, and has a flag and/or back-ptr to the ref-object telling
> wheter it's still live or not, to avoid storing
> pointers-to-weak-pointers as I do. (I've probably lost you now, right?) :)
A little, but I can still see your taillights. ;)
> What is needed is a way to go from * to shared, you mean? Well, to do
> that you need to find the ref-count & deletor-storage for a certain ptr.
> With intrusive counting it's trivial, because it lies in the pointed to
> object. With non-intrusive mapping, you need a map somewhere. You could
> simply store a set of shared_ptr's and do a lookup there. That's what
> you're doing for FCPtr's anyway, no? (It'd be a bit awkward and not very
> efficient at all though to do that every time)
For efficiency reasons I was thinking about doing intrusive anyway, so that
shouldn't be a problem.
> However, boost::shared_ptr is quite slow compared to c-ptrs or
> intrusive_ptrs. I've done some measurements and it's quite horrible. It
> does matter in a few places if you use these pointers alot
> (stl-containers etc), due to cache trashing when accessing the ref-count
> value.
Hm, that doesn't sound good. I was hoping to be able to reuse the
boost::shared_count pieces, because they have nice system-specific lock-free
threadsafe operations. But the way they implement the weak count doesn't allow
actually including the sp_counted_base in the class, it has to be a pointer,
which is not needed for an intrusive version.
Where did you run into performance issues? I would hope that in general there's
no need to access the refptr very often. I can see a problem for resizing
vectors and copying over all the contents, but I don't really expect to see a
lot of that in OpenSG, at least not for big vectors. The big stuff (vertices
etc.) won't be refcounted. For vectors there should be a way to use swap
instead
of copy to make the whole thing more efficient, but I haven't looked into the
very deeply.
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
