c# - ReaderWriterLockSlim vs. Monitor

multithreading locking

Question

Tengo una IDictionary<TKey,TValue> que contiene internamente n otro Dictionary<TKey, TValue> y distribuye esas inserciones por el HashCode de la clave a los diccionarios secundarios. Con 16 diccionarios secundarios, el número de colisiones es bastante bajo en una máquina de 4 núcleos.

Para las inserciones paralelas, ReaderWriterLockSlim el Add-method con un ReaderWriterLockSlim , bloqueando solo el sub-diccionario individual:

  public void Add(TKey key, TValue value)
        {
            int poolIndex = GetPoolIndex(key);
            this.locks[poolIndex].EnterWriteLock();
            try
            {
                this.pools[poolIndex].Add(key, value);
            }
            finally
            {
                this.locks[poolIndex].ExitWriteLock();
            }
        }

Al insertar elementos con cuatro hilos, solo obtuve un 32% de uso de la CPU y un mal rendimiento. Así que reemplacé el ReaderWriterLockSlim por un Monitor (es decir, la palabra clave de lock ). El uso de la CPU ahora era casi del 100% y el rendimiento se duplicó con creces.

Mi pregunta es: ¿Por qué aumentó el uso de la CPU? El número de colisiones no debería haber cambiado. ¿Qué hace que ReaderWriterLock.EnterWriteLock espere tantas veces?

Answer 1

¿Cómo sabes qué causó el mal rendimiento? No se puede adivinar, la única forma es hacer algún tipo de perfil.

¿Cómo maneja el bloqueo para la colección padre o es constante?

¿Quizás necesites agregar algún resultado de depuración y ver qué sucede realmente?

Answer 2

No soy un gurú, pero supongo que RWLS está más orientado a una fuerte contención (por ejemplo, cientos de subprocesos) mientras que Monitor está más en sintonía con esos problemas únicos de sincronización.

Personalmente utilizo una clase TimerLock que usa Monitor.TryEnter con un parámetro de tiempo de espera TimerLock .

Answer 3

Para la carga de solo escritura, el Monitor es más económico que ReaderWriterLockSlim; sin embargo, si simula la carga de lectura y escritura donde la lectura es mucho mayor que la escritura, entonces ReaderWriterLockSlim debería superar a Monitor.