Unsynchronized data races
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
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- wasm
- Área
- compilers
Línea de trabajo
Comienza con la semántica de ejecución de memory.fill en la sección enlazada de la especificación de WebAssembly. Investiga las garantías para las lecturas concurrentes con memory.fill, incluido si se permiten observaciones parciales o no secuenciales, y aclara después la especificación una vez decidido el comportamiento.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
memory.fill is currently specified as writing its bytes sequentially from lowest address to highest: https://webassembly.github.io/spec/core/exec/instructions.html#xref-syntax-instructions-syntax-instr-memory-mathsf-memory-fill. This behavior is unobservable to the thread executing the instruction, and I would presume most implementations don't write a byte at a time. But with multiple threads, I understand the goal is to allow races. What do we guarantee in that case?
- Will a thread reading memory being concurrently filled via
memory.fillsee a linearly advancing fill? - Will a thread reading memory being concurrently filled via
memory.fillsee either the old data or the new data? Could it see something else?
I am particularly interested in the last question: is seeing something else allowed.
- Lenguaje dominante
- WebAssembly
- Estrellas
- 769
- Forks
- 54
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- 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 WebAssembly/threads
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
WebAssembly/threads#254 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
WebAssembly/threads#253 · 6 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
WebAssembly/threads#245 · 1 reacción ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
WebAssembly/threads#240 ·
-
Branch renamingAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 20/100
WebAssembly/threads#237 ·
Todos los issues de WebAssembly/threads
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
rubys/roundhouse#444 ·
Los mantenedores suelen responder en 1 día
-
crash llvm:codegen
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
llvm/llvm-project#229064 ·
Los mantenedores suelen responder en 1 día
-
vxc prints a debug line '[flat-codegen] emitted module via the flat path' on every compilePosiblemente ocupada @YodHeVauHe la tomó hoy. Abiertodevex good first issue
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 70/100
kmmbvnr/rank#196 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
SciML/ModelingToolkit.jl#5255 ·
Los mantenedores suelen responder en 1 día