On Mon, Jan 4, 2016 at 8:58 PM, Zoltán Herczeg <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
