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

>The biggest problem is having this working (and claim as supported)
>amongst the huge number of compilers and platforms that PCRE2 runs on.
>That's not an easy task.

this is exactly my problem :)

Perhaps we could start by supporting some platforms, and gradually cover more with the community help. I heard that asm volatile forces GCC (and perhaps clang) to disable moving instructions around such asm blocks.

E.g:

statement1;
asm volatile (" ");
statement2;

Is it true, that statement1 is fully completed before statement2 is executed even if the assembly part is nothing?

Hence:

ptr->member = something;
asm volatile (" ");
result_ptr->member = ptr;

is executed in-order?

The CPU can still reorder stores. An x86 CPU does not have (need) data write barrier instruction as far as I know. Recent ARM 32 CPUs has data write barrier. Could somebody tell me how can I test whether this instruction is available at compile time? ARM 64 should not be a problem. I have not checked other CPUs yet.

There is one more thing. This theoretically affects everything, not just JIT compilation. If we compile a pattern with pcre2_compile, it is possible that the result pointer has been shared with another thread, but the compiled pattern data is not.

Main thread:

compiled_pcre_pattern->byte_code = something;
return compiled_pcre_pattern;

shared_pattern = compiled_pcre_pattern;

Another thread:
match (shared_pattern, subject);

The byte_code part can be a garbage on the other thread (since it can be executed by another CPU). People did not complain about these effects before, is there a reason for that? I don't want to solve a non-existing problem.

Regards,
Zoltan