Hi Christophe,
On Fri, 2004-08-20 at 10:47, Christophe Delépine wrote:
> Hi Dirk
>
> Well, i had a quick look into the header files and it seems that
> multithreading is based on a one writer, multi reader approach
>
> Here is what happens when a thread calls beginEdit to modify a NVSG
> object (extracted from Object.h)
>
> * Initiates a safe edit operation on an NVSG Object.
> *
> * The function returns when the calling thread successfully obtained
> write access to the object.
> * If the object is currently locked for write or read access from a
> concurrent thread, the calling thread
> * enters the wait state. It uses no processor time while waiting to
> obtain write access.
> *
> * After getting write access to the object, the function returns a
> pointer to the non-const object.
> * Throught this pointer, the const and especially the non-const
> interface of the object can be accessed.
> *
> * When the function returns, the object is protected against any
> write or read access from concurrent threads.
> * After the desired edit operation has been completed, the write
> lock for the object must be released through
> * a corresponding call to \link nvsg::endEdit endEdit \endlink.
> Missing the endEdit call after completing the
> * edit operation can cause the system to become deadlocked!
> *
> * \returns A pointer to the now writable object.
> *
>
> This is radically different from what is done in OpenSG where readers
> can still access to the original data while writers modify it
>
> Do you think Nvidia approach is bad ?
Wow! And I thought our begin/endEdit was painful! ;) But this is pretty
serious, if you forget one call, your object is deadlocked. And given
that it's only that one object, this might only show up much later. Even
worse, if you're a good guy writing error-resistant code (using
timeouts), you might actually not see it, because your code quietly
waits for the object to become available while working on other things.
It's going to be interesting to see how people like the system and how
often they have problems. You could probably use some scripts on the
trace output they generate, not sure how useful that is going to be as
they apparently only output the function name.
Besides being somewhat painful to use, their approach strongly depends
on mutex access being essentially free, because you have to assert a
mutex every time you write OR read any data from the object. For a
single processor system that might even be true, but if you have
multiple processors in your system, I strongly doubt that to be a valid
assumption. I don't have hard test data for Intel/AMD systems for this
(any pointers very welcome), but in my experience with SGI systems lock
access was always a costly issue. And they had special hardware for
locks, but it was limited to a pretty small number (AFAIR 8192). Given
that NVSG uses a lock (or actually 3) per object, it will probably blow
any limit on dedicated locks. But (this is a big but) I don't have hard
data on the cost of locks. If anybody has a good documentation how locks
are handled on Intel/AMD systems, I'd be very interested.
OpenSG was built on the assumption that lock access is not cheap, and
should be avoided as much as possible. Therefore we limited locking to
the places where it is unavoidable and that is pretty much nowhere. ;)
The only place where OpenSG needs locks is accessing the reference
counts of objects (which is why our default pointers are not smart, as
that would mandate lots of refcount changes on passing parameters
around). Everything else works without locks, as every thread has a
private copy of the data it can happily change without interfering with
any other thread's data.
The price you pay for that is having multiple copies of the data. We
limit the actual cost of that by sharing the large arrays that contain
vertex and pixel data (actually we share all MField data, but that's
just for implementation simplification). When a thread starts to change,
that's the point it allocates and fills a copy, and the writer thread
pays the price for that in terms of processing time, so all readers are
unaffected. One major motivation for the current Field rewrite is to
reduce the memory overhead of the additional copies even further by
moving out the vtable pointer from the Fields (which for small Fields
can make a significant difference).
That's an efficiency issue that I can see being problematic, but the
bigger problem I see is a conceptual one. The NVSG approach has been
done by other systems before (I know OpenRM does it, and it's an obvious
enough approach that I expect there are a couple more), and I'd like to
call it multithreading-light. ;) Essentially it ensures single object
consistency, but not graph consistency.
If I have a simulation that changes a number of objects, let's say I
have a physical simulation that moves everything according to gravity,
collision etc. These things take time, so you might want to run it in a
parallel thread. If you have a rendering thread that is faster than the
simulation, you're going to see partial results, i.e. some objects have
been moved, some have not. To avoid that you'd have to lock every object
until you've updated them all, and then unlock them all. But that would
essentially force you to go single-threaded, which doesn't need the
whole locking in the first place.
That's not nice, but seeing some object move a little late is probably
not a big deal to most people. It becomes interesting if another
simulation depends on the results, or if another (input) thread is
changing data, too. Because simulations do care about everything moving
at the right time, and if stuff moves inconsistently, all bets are off.
OpenSG avoids that by giving each thread a complete copy, which it can
change as much as it wants without affecting any other thread.
Summing up I think NVSG seems to be more painful to use than OpenSG (and
we're working on getting rid of the begin/endEdit anyway), and it might
run into performance issues with locks. Given all that, it doesn't
really solve the multi-threading issue in general, but only a limited
subset.
But it's from nVidia and therefore fast by definition, we're going to
see how that affects acceptance, even if it's not Open Source.
Yours
Dirk
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
