After an ``++await++``ed ``++Task++`` has executed, you can continue execution in the original, calling thread or any arbitrary thread. Unless the rest of the code needs the context from which the ``++Task++`` was spawned, ``++Task.ConfigureAwait(false)++`` should be used to keep execution in the ``++Task++`` thread to avoid the need for context switching and the possibility of deadlocks.
This rule raises an issue when code in a class library targeting .Net Framework ``++await++``s a ``++Task++`` and continues execution in the original calling thread.
The rule does not raise for .Net Core libraries as there is no ``++SynchronizationContext++`` in .Net Core.
Note [~tamas.vajk] that because I anticipate FP's from this rule, I've turned it on in the Security profile but not in SonarQube Way. Unless you're good enough to tell if execution _must_ pick back up in the main thread & ignore those instances?
=== on 2 Jul 2015, 07:02:20 Tamas Vajk wrote:
\[~ann.campbell.2] Thanks, it looks good. We'll see the FPs: we can automatically exclude "exe" projects, ...
=== on 21 Aug 2015, 06:18:04 Tamas Vajk wrote:
\[~ann.campbell.2] Do you think this is a security issue as well?
=== on 21 Aug 2015, 12:24:45 Ann Campbell wrote:
\[~tamas.vajk] I'm kinda in a bind: Critical rules must be bugs or security-related. Since multi-threading issues can affect security, I added the security tag rather than downgrading the severity.
=== on 21 Aug 2015, 12:28:28 Tamas Vajk wrote:
\[~ann.campbell.2] I see. It's more like a bug rule, but it is just a potential bug, so maybe we should reduce the severity to major.