sync: fix race on poolprocessor

[felipensp]

This PR fixes a race spotted by Helgrind running on same repo used on issue #23980

==12656== Possible data race during read of size 8 at 0xAAC5A20 by thread #1
==12656== Locks held: none
==12656==    at 0x4D0DFB: sync__pool__PoolProcessor_get_results_ref_T_v__gen__c__Gen (pool.c.v:152)
==12656==    by 0x740243: v__gen__c__gen (cgen.v:388)
==12656==    by 0x8AC1BC: v__builder__cbuilder__gen_c (cbuilder.v:80)
==12656==    by 0x8ABD84: v__builder__cbuilder__build_c (cbuilder.v:60)
==12656==    by 0x8ABBDC: v__builder__cbuilder__compile_c (cbuilder.v:50)
==12656==    by 0x8AA3AD: v__builder__Builder_rebuild (rebuilding.v:325)
==12656==    by 0x8A1281: v__builder__compile (compile.v:17)
==12656==    by 0x8B14B2: main__rebuild (v.v:193)
==12656==    by 0x8B09FE: main__main (v.v:151)
==12656==    by 0x8BBA58: main (v2.01JQ20DDCQ9XRY2AECS26KTMJK.tmp.c:236859)

[huly-for-github]

Connected to Huly®: V_0.6-22416

[medvednikov]

A great find!

[spytheman]

The way sync.PoolProcessor works/is used, there is no way for threads to race.

Each of the threads in the pool work on items, on which other threads do not (see the implementation of the process_in_thread method).

Only after all the work is done by the work_on_items/1 method, the main thread, that started the pool, uses the get_result/1 method .

I guess that there is no harm to use shared locks/mutexes, to reduce the number of false positives, but it is not an actual race.

[spytheman]

The gcc-windows failure is unrelated. I've already bumped its timeout to 90 minutes on master.