[pypy-issue] Issue #2623: Theoretical memory consistency problem in rpython signal handling (pypy/pypy)

Nathaniel Smith issues-reply at bitbucket.org
Fri Aug 4 14:23:49 EDT 2017


New issue 2623: Theoretical memory consistency problem in rpython signal handling
https://bitbucket.org/pypy/pypy/issues/2623/theoretical-memory-consistency-problem-in

Nathaniel Smith:

Here's `pypysig_pushback`:

```python
void pypysig_pushback(int signum)
{
    if (0 <= signum && signum < NSIG)
      {
        pypysig_flags[signum] = 1;
        pypysig_occurred = 1;
        pypysig_counter.value = -1;
      }
}
```

For correctness, it requires that the write to `pypysig_flags` happens-before the write to `pypysig_occurred`, because of how `pypysig_poll` is written. However, on most CPU architectures this is not guaranteed – the variables here are marked `volatile` which prevents the C compiler from rearranging the stores, but it doesn't do anything to prevent the cache hierarchy from rearranging the stores.

`pypysig_pushback` and `pypysig_poll` should use something like `stdatomic.h` when storing/loading these variables to ensure that proper memory fences are included.

On x86/x86-64 you can probably get away with this, and on Unix the signal handler usually (but not always) runs in the main thread, so it's not likely that anyone is hitting this in practice, but in theory any code that relies on `volatile` for cross-thread synchronization is just wrong.

CPython version of this bug: https://bugs.python.org/issue31119




More information about the pypy-issue mailing list