ReadWriteLock performance problems


#1

Our codebase has a diverged ReadWriteLock to the main JUCE one as we were having performance problems. Unfortunately it uses some PooledObject code from elswhere in our codebase so can’t really be a Pull Request. @Jonathan_Earnshaw might be able to help with more detail as to why it is like this but it would be good to sync upstream.

/** JE 24/09/15: Copied from juce::ReadWriteLock with the following fixes/improvements:
 *
 * The main issue with the juce version of this class is that all waiting threads
 * are using the same WaitableEvent. A writer thread can easily timeout on
 * a wait() when a waiting reader thread resets the event trigger before the writer
 * thread can check it. This can add upto 100ms for each writelock attempt when 
 * there are multiple readers waiting. The same issue can be seen in the reader only
 * case where only 1 reader is woken from the wait() and the rest acquire the readlock
 * after their wait() timeouts.
 *
 * To fix this, each waiting lock gets it's own WaitableEvent from an object pool.
 * The WaitableEvent's are separated to avoid unnecessarily waking up reader
 * threads when they won't be able to acquire the lock. The wait timeout has been
 * removed because it is no longer needed which also prevents unnecessary wakeups.
 */