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

Romain Vimont rom at rom1v.com
Fri Apr 6 16:09:55 CEST 2018


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.

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

> 
> -- 
> 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/
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list