On 11/18/15 6:22 PM, Matt Morehouse wrote:
> While doing some random testing of Firefox, I encountered the assertion failure MOZ_ASSERT(IsIdle(oldState) || IsRead(oldState)) in Checker::StartReadOp() in xpcom/glue/pldhash.h. It seems that this failure is the result of concurrent readers and writers to the same instance of PLDHashTable.
Or, possibly, reentry. What did the stack look like?
> It seemed odd to me that there would be code to check for concurrent readers and writers but no code to prevent such concurrent accesses
PLDHashTable is single-threaded. It's not meant to be used in any sort
of concurrent way at all. This code is checking for reentry, really.
> so I decided to add some basic synchronization with a pthread_rwlock_t.
Note that in the reentry case this would probably deadlock....
> While this approach did fix the assertion failure
Sounds like you were actually getting concurrent access, then. I'd
_really_ like to see the stack at that assertion failure.
> Is this the reason that PLDHashTable is currently left unsynchronized?
Well, that, and that it's not meant to be used in any sort of concurrent
manner that involves thread.
> What is PLDHashTable being used for that requires so many concurrent accesses?
It's the main hashtable implementation used outside the JS engine. Used
for all sorts of stuff in the DOM, layout, and so forth.
-Boris