On 10/23/2017 10:24 PM, Michael Niedermayer wrote: > On Tue, Oct 24, 2017 at 01:39:03AM +0100, Mark Thompson wrote: >> On 24/10/17 00:52, Michael Niedermayer wrote: >>> Hi >>> >>> On Mon, Oct 23, 2017 at 04:43:19PM +0100, Mark Thompson wrote: >>>> On 23/10/17 03:56, Michael Niedermayer wrote: >>>>> the initialization should be thread safe as it never writes a different >>>>> value in the same spot >>>> >>>> This is not true; please be very careful with assumptions like this. >>>> >>>> The C standard calls this a data race and it is undefined behaviour. >>> >>> Thats interresting, we definitly do not want undefined behavior >>> can you quote the relevant parts of the C standard >>> which make writing the same value, a data race ? >>> >>> I was not aware of this if its true. >>> Also i dont immedeatly see this in the "latest" draft i am looking at >>> atm >>> >>> What i see is this: >>> 4 Two expression evaluations conflict if one of them modifies a memory >>> location and the >>> other one reads or modifies the same memory location. >>> ... >>> 25 The execution of a program contains a data race if it contains two >>> conflicting actions in >>> different threads, at least one of which is not atomic, and neither >>> happens before the >>> other. Any such data race results in undefined behavior. >>> >>> This seems carefully worded to not include writing the same value. >>> As "modification" implies change which does not occur when writing the >>> same value. >> >> All writes are modifications. >> >> See section 3.1 note 2: >> """ >> 3 NOTE 2 "Modify"€™ includes the case where the new value being stored is >> the same as the previous value. >> """ > > That resolves the difference between our interpretation > > thanks
Should i push this, or does someone want to give ff_thread_once() a try? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
