(speaking from a position of zero knowledge of LO's threading stuff, but having spent way too much time chasing threading gunk in general ..)
Michael Meeks wrote: > > So - I'm with Kohei mostly - lets not do over-expensive, > > non-inline-able nonsense atomic operations when we don't need to. You make it sound like atomic implies non-inlinable. I don't see that. Thorsten Behrens wrote: > You need them. Until you've eliminated almost all of the above. > Refcount races are *surely* much worse than the speed penalty of > atomic counts. Not comparable, though (?) Refcount races lead to crashes. Atomic counts lead to slowness. If it's any use .. recent versions (3.6.x) of Valgrind/Callgrind can count atomic ops, so you can see what call chains lead to large numbers of atomic ops. Also, it means you can get some crude cycle count estimates of the amount of time you're waiting for atomic ops, if you assume a worst case of (eg) 200 cycles per atomic op. It's a lot less if you hit in D1; I measured ~11 cycles for atomic add on Core 2 in the best case. Valgrind/Helgrind can find refcount races if you want. It requires a few lines of markup to describe the synchronisation effects of threadsafe refcounting, but that's no big deal. --- The scheme used in Firefox is (I think) that you can more or less have your cake and eat it: you can ask for a class to be threadsafe refcounted (slow, but safe) or thread-unsafe refcounted (faster, but dangerous). In the latter case, debug builds check that calls to AddRef/Release are done by the same thread that allocated the object, hence detecting any refcount races. So in fact you're pretty safe providing the test suite has enough coverage. J _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
