A shared resource refers to a resource or data that can be accessed or modified by multiple threads or concurrent parts of a program. It could be any piece of data, object, file, -database connection, or system resource that needs to be accessed or manipulated by multiple parts of a program concurrently.
-Shared resources should not be used for locking as it increases the chance of -deadlocks. Any other thread could acquire (or attempt to acquire) the same lock while doing some -operation, without knowing that the resource is meant to be used for locking purposes.
-One example of this is a String interned by the runtime. This
-means that each String instance is immutable and stored, and then reused everywhere it is referenced.
Instead, a dedicated private object instance should be used for each shared resource. Making the lock-specific object
-private guarantees that the access to it is as minimal as possible, in order to avoid deadlocks or lock contention.
Shared resources should not be used for locking because it increases the chance +of deadlocks. Any other thread could acquire (or attempt to acquire) the same lock while doing +some operation, without knowing that the resource is meant to be used for locking purposes.
+For example, a string should never be used for locking. When a string is interned by the runtime, it can be shared by multiple threads, breaking the
+locking mechanism.
Instead, a dedicated private object instance should be used for each shared resource. This minimizes access to the lock instance,
+avoiding deadlocks and lock contention.
The following objects are considered as shared resources:
Serialization event handlers that don’t have the correct signature will not be called, bypassing augmentations to the automated -de/serialization.
+Serialization event handlers that don’t have the correct signature will not be called, bypassing augmentations to automated serialization and +deserialization events.
A method is designated a serialization event handler by applying one of the following serialization event attributes:
-It is also possible to use AES-CBC with HMAC for integrity checks. However, it
-is considered more straightforward to use AES-GCM directly instead.
+It is also possible to use AES-CBC with HMAC for integrity checks. However, it is considered more straightforward to use AES-GCM directly +instead.
The Optimal Asymmetric Encryption Padding scheme (OAEP) adds randomness and a secure hash function that strengthens the regular inner workings of RSA.
diff --git a/analyzers/rspec/vbnet/S117.html b/analyzers/rspec/vbnet/S117.html index 0a7d010b846..6fcdd6f90b4 100644 --- a/analyzers/rspec/vbnet/S117.html +++ b/analyzers/rspec/vbnet/S117.html @@ -9,15 +9,17 @@Inconsistent naming of local variables can lead to several issues in your code:
In summary, not adhering to a naming convention for local variables can lead to confusion, errors, and inefficiencies, making the code harder to read, understand, and maintain.
diff --git a/analyzers/rspec/vbnet/S2551.html b/analyzers/rspec/vbnet/S2551.html index 2a41f990e96..22fbe0e6c5f 100644 --- a/analyzers/rspec/vbnet/S2551.html +++ b/analyzers/rspec/vbnet/S2551.html @@ -1,14 +1,15 @@A shared resource refers to a resource or data that can be accessed or modified by multiple threads or concurrent parts of a program. It could be any piece of data, object, file, -database connection, or system resource that needs to be accessed or manipulated by multiple parts of a program concurrently.
-Shared resources should not be used for locking as it increases the chance of -deadlocks. Any other thread could acquire (or attempt to acquire) the same lock while doing some -operation, without knowing that the resource is meant to be used for locking purposes.
-One example of this is a String interned by the runtime. This
-means that each String instance is immutable and stored, and then reused everywhere it is referenced.
Instead, a dedicated private object instance should be used for each shared resource. Making the lock-specific object
-private guarantees that the access to it is as minimal as possible, in order to avoid deadlocks or lock contention.
Shared resources should not be used for locking because it increases the chance +of deadlocks. Any other thread could acquire (or attempt to acquire) the same lock while doing +some operation, without knowing that the resource is meant to be used for locking purposes.
+For example, a String should never be used for locking. When a String is interned by the runtime, it can be shared by multiple threads, breaking the
+locking mechanism.
Instead, a dedicated private Object instance should be used for each shared resource. This minimizes access to the lock instance,
+avoiding deadlocks and lock contention.
The following objects are considered as shared resources: