¿Por qué ConcurrentQueue <T>. Count return 0 cuando IsEmpty == true?

Question

que estaba leyendo acerca de las nuevas clases de colección concurrentes en .NET 4 en James Michael Hare's blog y el page talking about ConcurrentQueue<T> dice:

Todavía se recomienda, sin embargo, que para los controles vacíos se llama IsEmpty en lugar de comparar cuenta a cero .

soy curioso - si hay una razón para utilizar IsEmpty en lugar de comparar Conde a 0, ¿por qué la clase no comprueba internamente IsEmpty y volver 0 antes de realizar cualquiera de los trabajos costosos para contar?

ej .:

public int Count 
{ 
    get 
    { 
     // Check IsEmpty so we can bail out quicker 
     if (this.IsEmpty) 
      return 0; 

     // Rest of "expensive" counting code 
    } 
} 

Parece extraño sugerir esto si pudiera ser "fijo" tan fácilmente sin efectos secundarios?

Answer 1

Te voy a enseñar una ejemplo exagerar:

public bool IsEmpty 
{ 
    get { /* always costs 10s here */ } 
} 

public int Count 
{ 
    get { /* always costs 15s here, no matter Count is 0 or 1 or 2... */ } 
} 

Si implementan la propiedad Count así:

public int Count 
{ 
    get 
    { 
     if (IsEmpty) return 0; 
     //original implementation here 
    } 
} 

Ahora, cuando el recuento final es 0, cuesta 10s (5s ¡menos que antes !, ¡genial!), pero para aquellos Count es 1/2/más, cuesta más que antes, ¡porque la comprobación de IsEmpty cuesta tiempo! Por lo tanto, la optimización no es una buena idea, porque IsEmpty lleva tiempo. Sería bueno si IsEmpty está leyendo directamente de un campo.

EDITAR he comprobado la implementaion de ambos IsEmpty y Count a través del reflector, ambos son caros . Obviamente, comprobar IsEmpty para 0 conteo reducirá la velocidad de rendimiento promedio.

Answer 2

IsEmpty proporciona cierta concurrencia hilo que si obtiene el valor Count y compararlo, está en el hilo, pero la cola podría ser cambiado.

MSDN dice:

Para determinar si la colección contiene ningún artículo, se recomienda el uso de este propiedad en lugar de recuperar el número de elementos de la propiedad Count y comparándolo con 0. Sin embargo, como se pretende acceder a esta colección simultáneamente, puede ocurrir que otro hilo modifique la colección después de IsEmpty devuelve, invalidando así el resultado .

Answer 3

ConcurrentQueue<T> está libre de cerrojo y usa espera de centrifugado para lograr un acceso simultáneo de alto rendimiento. La implementación simplemente requiere que se haga más trabajo para devolver el conteo exacto que para verificar si no hay elementos, por lo que se recomienda IsEmpty.

Intuitivamente, puede pensar en Count tener que esperar un lapso de tiempo cuando ningún otro cliente está actualizando la cola, para tomar una instantánea y luego contar los elementos en esa instantánea. IsEmpty simplemente tiene que verificar si hay al menos un artículo o no. Las operaciones concurrentes Enqueue y TryDequeue están cambiando el recuento, por lo que Count tiene que volver a intentarlo; a menos que la cola esté en transición entre los estados vacío y no vacío, las operaciones simultáneas no cambian el valor de retorno de IsEmpty, por lo que no tiene que esperar.

Escribí una aplicación de prueba sencilla de varios subprocesos que mostraba que Count era ~ 20% más lento (con contienda constante y sin contención); sin embargo, ambas propiedades se pueden llamar millones de veces por segundo, por lo que es probable que cualquier diferencia en el rendimiento sea completamente insignificante en la práctica.

Answer 4

Comprender cómo funcionan las estructuras concurrentes es muy importante.

if (isEmpty()) ...//do whatever

si tiene estructura concurrente el cheque está cerca de no operación desde todo puede cambiar entre estaVacia y cualquier operación posterior.

Count itera a través de los nodos (no han utilizado C# durante casi 6 años, pero el análogo de Java hace lo mismo) para calcular, por lo que es una llamada costosa. Respuesta directa: La comprobación es Vacía antes del conteo incurrirá en una valla de memoria adicional y no logrará nada. Editar: si no está claro. Cuente cuando la cola está vacía cuesta exactamente como está Vacío, sin embargo, cuesta mucho cuando la cola no es!

Cuenta similar a isEmpty para estructuras concurrentes tiene poco o ningún significado, ya que el resultado de la llamada puede no ser útil y cambiar mucho.