LongConcurrentHistogram.IncrementCountAtIndex — Two Atomic Operations Where One Suffices
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- csharp
- Área
- performance
Línea de trabajo
Start in LongConcurrentHistogram.cs at IncrementCountAtIndex and inspect TotalCount, including its Interlocked.Read usage. Compare the Java original and the mentioned Recorder pattern to understand the alternatives. Done means selecting and validating one approach for reducing recording atomic operations without breaking count correctness.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
File: LongConcurrentHistogram.cs
protected override void IncrementCountAtIndex(int index)
{
long criticalValue = _wrp.WriterCriticalSectionEnter();
try
{
_counts.IncrementAndGet(index); // Interlocked.Add
Interlocked.Increment(ref _totalCount); // second atomic op
}
finally { _wrp.WriterCriticalSectionExit(criticalValue); }
}
Every RecordValue call in the concurrent histogram pays for WriterCriticalSectionEnter (an Interlocked.Increment), Interlocked.Add on the count, Interlocked.Increment on _totalCount, and WriterCriticalSectionExit (another Interlocked.Increment). That's four atomic operations per record.
_totalCount is only read by TotalCount which already calls Interlocked.Read. Consider whether _totalCount needs to be updated atomically at all during recording, or whether it can be derived lazily by summing the array (expensive) or maintained with a Volatile.Write (cheaper). The Java original avoids this cost by using a single updater CAS. A Recorder-pattern approach (per-thread histograms merged on read) avoids the issue entirely and is the recommended usage pattern anyway.
- Lenguaje dominante
- C#
- Estrellas
- 185
- Forks
- 31
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de HdrHistogram/HdrHistogram.NET
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
HdrHistogram/HdrHistogram.NET#167 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
HdrHistogram/HdrHistogram.NET#166 ·
-
WriterReaderPhaser.FlipPhase - Task.Yield().GetAwaiter().GetResult() is a Thread Pool Anti-PatternAbiertoagent enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
HdrHistogram/HdrHistogram.NET#144 ·
-
agent enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
HdrHistogram/HdrHistogram.NET#142 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
HdrHistogram/HdrHistogram.NET#156 ·
Todos los issues de HdrHistogram/HdrHistogram.NET
Issues similares
-
needs-area-label
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Fallout-build/Fallout#708 ·
Los mantenedores suelen responder en 5 días
-
bug next version
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Rem0o/FanControl.Releases#4220 · 1 comentario ·
-
area:repo audit:approved audit:auto priority:P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
elsa-workflows/elsa-core#8771 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
nkdAgility/azure-devops-migration-tools#3217 ·
Los mantenedores suelen responder en 1 día