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

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



KO Myung-Hun wrote:
> 
> 
> Romain Vimont wrote:
>> On Fri, Apr 06, 2018 at 09:12:04PM +0900, KO Myung-Hun wrote:
>>>
>>>
>>> Romain Vimont wrote:
>>>> On Thu, Apr 05, 2018 at 08:40:57PM +0900, KO Myung-Hun wrote:
>>>>> And if it is 1, it's guaranteed that cb() has been completed. Because
>>>>> function call acts as memory barrier and it will not be reordered
>>>>
>>>> At least in theory, I think that a function call does not act as a
>>>> memory barrier.
>>>>
>>>
>>> Ok, at least compiler barrier according to your link.
>>
>> 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.
> 
> However, if moving cb() around, then it cannot be guaranteed that they
> are same. For example, cb() may depend on once->done in its internal.
> And compiler cannot see the internal of cb(). As a result, compiler
> should not reorder those parts, and neither CPU.
> 
>>>
>>>> And even if it did, so that cb() is guaranteed to be completed in the
>>>> first thread, the changes applied by cb() are not guaranteed to be
>>>> visible from the second thread (cache coherence).
>>>>
>>>> <https://stackoverflow.com/questions/10698253/is-function-call-an-effective-memory-barrier-for-modern-platforms>
>>>
>>> For the second thread to use the changes by cb(), it should see done
>>> first. And it can see done with 1, it should be able to see the changes
>>> by cb(). After all, is it possible that changes of cb are not applied
>>> but done is applied to each cache ?
>>
>> Yes, there is no guarantee that the second thread sees the changes
>> applied by cb() even if it sees the new value of done (there is no
>> synchronization). This is unlikely though.
>>
> 
> I've confirmed this may happen on DEC Alpha. But I'm not sure this is
> true for Intel x86. Would you mind providing any references for this ?
> 

In Intel Intel 64 and IA-32 Architectures Software Developer’s Manual
Volume 3A: System Programming Guide, Part 1 8.2.2:

In a multiple-processor system, the following ordering principles apply:
 Individual processors use the same ordering principles as in a
single-processor system.
 Writes by a single processor are observed in the same order by all
processors.
 Writes from an individual processor are NOT ordered with respect to
the writes from other processors.
 Memory ordering obeys causality (memory ordering respects transitive
visibility).
 Any two stores are seen in a consistent order by processors other than
those performing the stores
 Locked instructions have a total order.

As a result, at least on x86, second thread should see the changes by
cb() if it sees once->done which is 1.

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