Quantcast
Viewing all articles
Browse latest Browse all 70

Source code checked in, #06c83837ed492c481d8c8feedf8800798890cc1f

Fixes subtle potential race condition that could be allowed by the lowering of null-propagating operator. The general rule here is that compiler should not introduce reads to the same location on the heap. Doing so can introduce races to the user's code that otherwise does not have races. As a result of that it is ok to read a local variable multiple times, but only if the local cannot be modified in between reads and when it is known to not be captured into a closure. In particular at lowering stage (before lambda rewritings) without additional analysis we do not know if locals could be captured into closures and therefore shared with other threads and modified between reads. == in this change: Do not assume that reads of locals and byval parameters are idempotent if we do not know whether they may be captured in closures. Without additional analysis we can not make this assumption, so at the time of local rewrite we must conservatively consider locals and parameters as potentially returning different value every time they are evaluated. Note that nullables are excluded from this rule. That is because in the ?. operators over nullable we do not read the same location twice. We read "HasValue" and then conditionaly read ValueOrDefault. That is no different than just reading both values unconditionally - we would not introduce any new races if we do not cache the whole local between such reads. . (changeset 1341599)

Viewing all articles
Browse latest Browse all 70

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>