Hi Samar, > Consider the case where two threads are pointing to the same element > from a given document tree. As both of them destruct their handle object, > both handles will attempt to decrement the reference count and we could > end up with a race condition here. This MAY result in unpredictable > behavior, unless we implement the reference counting in a thread safe manner. > This is especially true on SMP machines. I may have this all wrong and > this may be thread-safe, in which case I apologize.
I had earlier stated that adding handles did not change IDOM's threading characteristics. Thanks for pointing out so nicely that I was wrong. It looks like we have the following choices: 1. Not support read-only thread safety. 2. Support read-only thread safety at the sacrifice of leaking memory and limiting implementation memory models (current IDOM). 3. Support read-only thread safety as you suggest by performing thread safe increments and decrements with the possibility that some performance is lost. If #3 does affect performance, then perhaps read-only thread safety can be made an option so that those that don't need it don't pay for it. > Simply by implementing thread safe increment/decrement, we can guarantee that > as long as NO CHANGES are made to the document itself, multiple threads can be > reading various parts of it. This is because on each object there will be at > least one handle holding a reference count (i.e. the main document itself), > hence no objects will need to be added to the allocator's free list. That is the case, no recycling is performed in a read-only situation, thus we don't need to protect the allocator. The whole document will get deleted, though, as soon as there are no handles to any of its nodes, so that is another reason why we will need to reference count in a thread safe manner to be read-only thread safe. Lenny --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
