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

KO Myung-Hun komh78 at gmail.com
Sun Apr 8 09:01:32 CEST 2018

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

>> 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/

More information about the vlc-devel mailing list