[vlc-devel] [PATCH 1/6] os2: implement vlc_once()

[KO Myung-Hun]

Rémi Denis-Courmont wrote:
> Le lauantaina 7. huhtikuuta 2018, 19.06.07 EEST KO Myung-Hun a écrit :
>>> At least a compiler barrier *in practice*, but not in theory (so this is
>>> not guaranteed). And the CPU might also reorder.
>>
>> Reordering of both a compiler and a CPU should guarantee that the result
>> of reordering is the same as the one of the sequential in a single thread.
> 
> Sure, all the provided patches work fine in the single thread case on any 
> platform.
> 
> But the whole point of vlc_once() is deal with multiple threads and concurrent 
> calls.
> 

Sure. But it was meant for the condition of reordering of a compiler and
CPU.

>> And compiler cannot see the internal of cb().
> 
> With LTO and IPA combined, a compiler can propagate vlc_CPU_init as the cb 
> value into vlc_once() from vlc_CPU().
> 

Then, are you saying that with them, compiler can reorder a call to
function pointer and others ?

> Not that it matters much. The problem is not a lack of release fence. 
> Unlocking the mutex provides a release fence. The problem is the lack fo 
> acquire fence before reading the flag.
> 

I'm saying that acquire fence is not necessary in this case, especially
on x86 because x86 guarantees "Writes by a single processor are observed
in the same order by all processors" in Intel Manual Vol 3A 8.2.2.

I admit that first patch is not portable, but I'm sure that it works on
x86 as expected.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.os2.kr/