[Libreoffice] Thread Safety

[Julian Seward]

(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