Re: [pcre-dev] PCRE2 and thread safety of jit compilation?

On Mon, Jan 4, 2016 at 8:58 PM, Zoltán Herczeg <hzmester@???> wrote:
> Probably a write barrier would make this perfect, but I am not an expert on that, and it requires CPU / OS dependent code.

Heh, it's not a "probably".

Although the pointer assignment itself is likely to be atomic on all
the architectures supported by PCRE, this is not guaranteed unless
you're using atomic types (_Atomic in C11), and especially the release
of the memory _pointed to_ is not atomic. Hence you truly need an
atomic pointer and load acquire / store release semantics (in C11:
atomic_store_explicit(jit_data, memory_order_release) in the thread
creating the JIT data, atomic_load_explicit(jit_data,
memory_order_acquire) in the threads performing atches), otherwise
you're triggering undefined behaviour due to a data race.

(Suppose the thread that performs the jit-study does something like:

jit_data *j = malloc(...);
j->field1 = 42;
j->field2 = "foo";
code->jit = j;

Without a release fence there's nothing preventing a CPU to reorder
these instructions to

code->jit = j;
j->field2 = "foo";
j->field1 = 42;

Hence causing havok on whatever reads code->jit and finds it to be
non-NULL but maybe filled with garbage)

Cheers,
--
Giuseppe D'Angelo