Review: Use reader/writer spin locks for ustring table.

[lgritz]

I wrote a reader/writer spin lock, used it for the ustring table, and it produces another significant improvement when there's heavy contention in ustring creation. In particular, with this patch the ustring performance continues to improve all the way up to the number of threads greater than the number of cores, whereas previously it "leveled off" earlier, with at some point additional HT cores not providing any additional benefit. Now, more cores always benefit. (For just a few cores, performance is the same as before.)

Now that this class is written, we could possibly improve performance by finding other places where a good spin rw lock is appropriate that's currently a purely exclusive lock.

[fpsunflower]

Is the compiler guaranteed to leave this alone ?

[lgritz]

atomic int has the actual bits underneath "volatile"

[c42f]

Should be ok I guess, since m_readers is atomic and inspecting its value expands to either a function call, an intrinsic or some inline assembler depending on the compilation environment. Any code using atomics is already subtly outside the C++98 standard memory model AFAIK, so guaranteeing behaviour becomes a bit difficult. I'm pretty confident the above would be ok in the C++11 standard though...

[fpsunflower]

LGTM

[c42f]

LGTM