DotNetVault 0.2.5.8

Synchronization Library and Static Analysis Tool for C# 8

     DotNetVault is a library and static code analysis tool that makes managing shared mutable state in multi-threaded applications more manageable and less error prone.  It also provides a common abstraction over several commonly used synchronization mechanisms, allowing you to change from one underlying type to another (such as from lock free synchronization to mutex/monitor lock based) without needing to refactor your code. Where errors do still occur, they are easier to locate and identify.

     The project description (a detailed design document) can be read here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/DotNetVault_Description_Latest_Draft.pdf.

     A quick start guide for installation (Windows, Vs 2019+) can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/QuickStart_Install_VS2019_Windows.md.

     A quick start guide for installation (Tested on Amazon Linux, Rider 2019.3.1+) can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/Quick_Start_Install_Rider_Amazon_Linux.md.

     A guided tour / quick start guide for this project's functionality can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/Quick_Start_Functionality_Tour.md

Install-Package DotNetVault -Version 0.2.5.8
dotnet add package DotNetVault --version 0.2.5.8
<PackageReference Include="DotNetVault" Version="0.2.5.8" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add DotNetVault --version 0.2.5.8
The NuGet Team does not provide support for this client. Please contact its maintainers for support.

DotNetVault

Synchronization Library and Static Analyzer for C# 8.0+

MAJOR NEW RELEASE (version 0.2.5.x)

DotNetVault takes its inspiration from the synchronization mechanisms provided
by Rust language and the Facebook Folly C++ synchronization library. These
synchronization mechanisms observe that the mutex should own the data they
protect. RAII destroys the lock when it goes out of scope – even if an
exception is thrown or early return taken. DotNetVault provides mechanisms for
RAII-based thread synchronization and actively prevents (at compile-time) resources protected by it from thread-unsafe or non-synchronized access.

Advantages:

Easy to Change Underlying Synchronization Mechanisms

DotNetVault uses a variety of different underlying synchronization mechanisms:

  • Monitor + Sync object
  • Atomics
  • ReaderWriterLockSlim

If you use them directly, and decide to switch to (or try) a different mechanism, it will require extensive refactoring DotNetVault simplifies the required refactoring. All vaults expose a common compile-time API.

Deadlock Avoidance

Using DotNetVault, all access is subject to RAII, scoped-based lock acquisition and release. Failure to obtain a lock throws an exception --- there can be no mistake as to whether it is obtained. When a locks scope ends, it is released. By default, all lock acquisitions are timed -- you must explicitly and clearly use the differently and ominously named untimed acquisition methods if you wish to avoid the slight overhead imposed by timed acquisition. (Typically after using and heavily testing using the standard timed acquisition methods, ensuring there are no deadlocks, profiling and discovering a bottleneck caused by timed acquisition, and then switching to the untimed acquisition method in those identified bottlenecks. It is hard to deadlock accidentally in DotNetVault.

RAII (Scope-based) Lock Acquisition and Release:

Locks are stack-only objects (ref structs) and the integrated Roslyn analyzer forces you to declare the lock inline in a using statement or declaration, or it will cause a compilation error.

  • There is no danger of accidentally holding the lock open longer than its scope even in the presence of an exception or early return.
  • There is no danger of being able to access the protected resource if the lock is not obtained.
  • There is no danger of being able to access the protected resource after release.
Enforcement of Read-Only Access When Lock is Read-Only

ReaderWriterLockSlim is unique among the synchronization primitives employed by DotNetVault in allowing for multiple threads to hold read-only locks at the same time. DotNetVault not only prevents access to the underlying resource while the correct lock is not held, it also enforces that, while a read-only lock is held, the protected object cannot be mutated. This is also enforced statically, at compile-time.

Isolation of Protected Resources

Static enforcement prevents unsynchronized access to protected resources.

Resources For Learning To Use DotNetVault

Quick Start Guides
  1. A quick-start installation guide for installing the DotNetVault library and analyzer for use in Visual Studio 2019+ on Windows.
  2. A quick start installation guide for installing the DotNetVault library and analyzer for use in JetBrains Rider 2019.3.1+ (created on an Amazon Linux environment, presumably applicable to any platform supporting JetBrains Rider 2019.3.1+).
  3. A guided overview of the functionality of DotNetVault along with a test project available on Github in both source and compiled code.

Development Roadmap

Release History

The last official release was version 0.1.5.4, available as a Nuget package here. Since then, many features have been added to DotNetVault. All of these features were included in the feature-complete beta version 0.2.2.12-beta, available as a Nuget package here. The following list is a non-exhaustive summary of these new features:

  • Upgrading to new versions of Roslyn libraries, immutable collections and other minor dependency upgrades
  • Changing some of the formatting of analyzer diagnostics to comply with Roslyn authors' recommendations
  • Adding Monitor Vaults (using Monitor.Enter + sync object) as the synchronization mechanism
  • Adding ReadWrite Vaults (using ReaderWriterLockSlim) as their synchronization mechanism
  • Fixing flawed static analyzer rules
  • Adding new analyzer rules to close encountered loopholes in the ruleset that potentially allowed unsynchronized access to protected resource objects
  • Unit tests as appropriate for new functionality
  • Creation of quick start installation guides with test projects
  • Not including project pdfs in the released package but instead providing an md document and a txt document with links to those documents in the github repository
  • Significant updates to the formatting and content of project markdown documents
  • Adding Source Link and releasing a symbol package along with the nuget package for this project
  • Writing many test projects and demonstration projects to verify functionality, stress test and profile performance of the vaults
  • Adding a document serving as a guide to using large mutable value types generally and as a repository for shared mutable state
Version / Branch 0.2.5.x

No major new features will be added to version 0.2.5. Development will remain open in the 0.2.5 branch primarily for refinements, bug fixes and documentation updates. Versions 0.2.5+ will continue to support .NET Framework 4.8, .NET Standard 2.0+ and .NET Core 3.1+ but will not make use of any features from the upcoming Version 5 of the unified DotNet framework. If you are not upgrading your projects to .NET 5, continue to use releases numbered 0.2 but make no upgrade to any package versioned 0.3+.

See DotNetVault Description.pdf which serves as the most complete design document for this project.

DotNetVault

Synchronization Library and Static Analyzer for C# 8.0+

MAJOR NEW RELEASE (version 0.2.5.x)

DotNetVault takes its inspiration from the synchronization mechanisms provided
by Rust language and the Facebook Folly C++ synchronization library. These
synchronization mechanisms observe that the mutex should own the data they
protect. RAII destroys the lock when it goes out of scope – even if an
exception is thrown or early return taken. DotNetVault provides mechanisms for
RAII-based thread synchronization and actively prevents (at compile-time) resources protected by it from thread-unsafe or non-synchronized access.

Advantages:

Easy to Change Underlying Synchronization Mechanisms

DotNetVault uses a variety of different underlying synchronization mechanisms:

  • Monitor + Sync object
  • Atomics
  • ReaderWriterLockSlim

If you use them directly, and decide to switch to (or try) a different mechanism, it will require extensive refactoring DotNetVault simplifies the required refactoring. All vaults expose a common compile-time API.

Deadlock Avoidance

Using DotNetVault, all access is subject to RAII, scoped-based lock acquisition and release. Failure to obtain a lock throws an exception --- there can be no mistake as to whether it is obtained. When a locks scope ends, it is released. By default, all lock acquisitions are timed -- you must explicitly and clearly use the differently and ominously named untimed acquisition methods if you wish to avoid the slight overhead imposed by timed acquisition. (Typically after using and heavily testing using the standard timed acquisition methods, ensuring there are no deadlocks, profiling and discovering a bottleneck caused by timed acquisition, and then switching to the untimed acquisition method in those identified bottlenecks. It is hard to deadlock accidentally in DotNetVault.

RAII (Scope-based) Lock Acquisition and Release:

Locks are stack-only objects (ref structs) and the integrated Roslyn analyzer forces you to declare the lock inline in a using statement or declaration, or it will cause a compilation error.

  • There is no danger of accidentally holding the lock open longer than its scope even in the presence of an exception or early return.
  • There is no danger of being able to access the protected resource if the lock is not obtained.
  • There is no danger of being able to access the protected resource after release.
Enforcement of Read-Only Access When Lock is Read-Only

ReaderWriterLockSlim is unique among the synchronization primitives employed by DotNetVault in allowing for multiple threads to hold read-only locks at the same time. DotNetVault not only prevents access to the underlying resource while the correct lock is not held, it also enforces that, while a read-only lock is held, the protected object cannot be mutated. This is also enforced statically, at compile-time.

Isolation of Protected Resources

Static enforcement prevents unsynchronized access to protected resources.

Resources For Learning To Use DotNetVault

Quick Start Guides
  1. A quick-start installation guide for installing the DotNetVault library and analyzer for use in Visual Studio 2019+ on Windows.
  2. A quick start installation guide for installing the DotNetVault library and analyzer for use in JetBrains Rider 2019.3.1+ (created on an Amazon Linux environment, presumably applicable to any platform supporting JetBrains Rider 2019.3.1+).
  3. A guided overview of the functionality of DotNetVault along with a test project available on Github in both source and compiled code.

Development Roadmap

Release History

The last official release was version 0.1.5.4, available as a Nuget package here. Since then, many features have been added to DotNetVault. All of these features were included in the feature-complete beta version 0.2.2.12-beta, available as a Nuget package here. The following list is a non-exhaustive summary of these new features:

  • Upgrading to new versions of Roslyn libraries, immutable collections and other minor dependency upgrades
  • Changing some of the formatting of analyzer diagnostics to comply with Roslyn authors' recommendations
  • Adding Monitor Vaults (using Monitor.Enter + sync object) as the synchronization mechanism
  • Adding ReadWrite Vaults (using ReaderWriterLockSlim) as their synchronization mechanism
  • Fixing flawed static analyzer rules
  • Adding new analyzer rules to close encountered loopholes in the ruleset that potentially allowed unsynchronized access to protected resource objects
  • Unit tests as appropriate for new functionality
  • Creation of quick start installation guides with test projects
  • Not including project pdfs in the released package but instead providing an md document and a txt document with links to those documents in the github repository
  • Significant updates to the formatting and content of project markdown documents
  • Adding Source Link and releasing a symbol package along with the nuget package for this project
  • Writing many test projects and demonstration projects to verify functionality, stress test and profile performance of the vaults
  • Adding a document serving as a guide to using large mutable value types generally and as a repository for shared mutable state
Version / Branch 0.2.5.x

No major new features will be added to version 0.2.5. Development will remain open in the 0.2.5 branch primarily for refinements, bug fixes and documentation updates. Versions 0.2.5+ will continue to support .NET Framework 4.8, .NET Standard 2.0+ and .NET Core 3.1+ but will not make use of any features from the upcoming Version 5 of the unified DotNet framework. If you are not upgrading your projects to .NET 5, continue to use releases numbered 0.2 but make no upgrade to any package versioned 0.3+.

See DotNetVault Description.pdf which serves as the most complete design document for this project.

Release Notes

RELEASE NOTES VERSION 0.2.5.8:
     * Update dependencies.
     * Add dependency to High-Precision-Timestamps v0.1.0.0
     * Use monotonic DateTimes from High-Precision-Timestamps to compute durations and timeouts
     * Rename VaultSafeWhiteList.txt to vaultsafe
     .txt
     
RELEASE NOTES VERSION 0.2.5.3:

     * Fixed problem with SourceLink not working correctly.
     * Fixed bug (Issue #2) that would throw a recursion exception sometimes when, using certain combinations of overloads, acquiring upgradable readonly locks then upgrading them would throw a lock recursion exception.
     * Update the quick start functionality tour and installation guides to use pictures reflecting more recent versions.
     
     RELEASE NOTES VERSION 0.2.5.0:

     The last official release was version [0.1.5.4](https://github.com/cpsusie/DotNetVault/releases/tag/v0.1.5.4),
     available as a Nuget package (DotNetVault/0.1.5.4).  Since then, **many** features have been added to DotNetVault:

     * Upgrading to new versions of Roslyn libraries, immutable collections and other minor dependency upgrades
     * Changing some of the formatting of analyzer diagnostics to comply with Roslyn authors' recommendations
     * Adding Monitor Vaults (using Monitor.Enter + sync object) as the synchronization mechanism
     * Adding ReadWrite Vaults (using ReaderWriterLockSlim) as their synchronization mechanism
     * Fixing flawed static analyzer rules
     * Adding new analyzer rules to close encountered loopholes in the ruleset that potentially allowed unsynchronized access to protected resource objects
     * Unit tests as appropriate for new functionality
     * Creation of quick start installation guides with test projects
     * Not including project pdfs in the released package but instead providing an md document and a txt document with links to those documents in the github repository
     * Significant updates to the formatting and content of project markdown documents
     * Adding Source Link and releasing a symbol package along with the nuget package for this project
     * Writing many test projects and demonstration projects to verify functionality, stress test and profile performance of the vaults
     * Adding a document serving as a guide to using large mutable value types generally and as a repository for shared mutable state

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version History

Version Downloads Last updated
0.2.5.8 34 12/14/2020
0.2.5.3 211 10/25/2020
0.2.5.1 120 10/14/2020
0.2.5 125 10/11/2020
0.2.2.12-beta 109 8/23/2020
0.2.2.1-beta 237 7/12/2020
0.2.1.22-beta 157 4/7/2020
0.2.1.9-alpha 257 3/15/2020
0.2.0.2-alpha 146 2/13/2020
0.1.5.4 218 2/17/2020
0.1.5.2 167 2/8/2020
0.1.5 175 2/2/2020
0.1.4.2-beta 317 2/1/2020
0.1.4.1-beta 275 1/26/2020
0.1.4-beta 245 1/21/2020
0.1.3.13-beta 262 1/11/2020
0.1.3.11-beta 294 1/8/2020
0.1.3.8-beta 410 1/4/2020
0.1.3.5-beta 311 1/1/2020