CodeQL queries 1.23
Data which is accessed concurrently from multiple threads is vulnerable to race conditions
and other errors.
lock statements are often needed to make concurrent code correct and ensure
that the data is consistent. However
lock statements must be used consistently on
all methods which are potentially called concurrently.
When there is a
lock statement on a property setter, it implies that the property could be
assigned to concurrently, so the property could also be read concurrently.
lock statement is necessary on the property getter. Even simple getters
lock statement to ensure that there is a memory barrier when reading a field.
Examine the logic of the program to check whether the property could be read concurrently.
lock statement in the property getter if necessary.
Alternatively, remove the
lock statement from the property setter if it is
no longer needed.
This example shows a property setter which uses a
lock statement, but there is no
lock statement in the getter. This means that
count is not
GenerateDiagnostics(), and there is a read barrier missing from the
property getter, which could cause bugs on some CPU architectures.
The solution is to add a
lock statement to the property getter, as follows: