[vlc-devel] [PATCH 1/6] os2: implement vlc_once()
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
> But the whole point of vlc_once() is deal with multiple threads and concurrent
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.
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