Sealable and Unsealable modifiers for each property #8421
Replies: 4 comments 5 replies
-
You can achieve runtime-sealing with a custom source generator (partial properties with generated check code). To identify them you can add an attribute like "RuntimeSealedAttribute". |
Beta Was this translation helpful? Give feedback.
-
The rest of the code looks quite strange in my eyes, e.g.: get
{
this.m_rwLock.EnterReadLock();
try
{
CacheAccessor<CacheData> cd = new CacheAccessor<CacheData>(this.m_cachedData, this.m_rwLock);
return cd;
} // End Try
catch (System.Exception ex)
{
this.m_rwLock.ExitReadLock();
throw;
}
} // End Getter You should use try-finally for the lock or use the lock keyword (see lock-object-proposal). The presented code leaks a read-lock when no exception is raised... |
Beta Was this translation helpful? Give feedback.
-
To understand you better, please format your code and mark it with "csharp". In markdown you can write: ```csharp
using System;
class Foo{
//what ever...
}
``` In addition make your code samples as small as possible. |
Beta Was this translation helpful? Give feedback.
-
Incorrect, if you do it in the finally-block, it will also unlock the rw-lock instantaneously, which is wrong. The idea is that you access the cache data (with r-lock), then access a few values, then exit the r-lock when finished using cache values. using(var CacheData = accessor.Data) // locking in the constuctor is wrong
{// here it needs to lock
// do something with CacheData.Value1
// do something with CacheData.Value2
// ...
// do something with CacheData.ValueN
} // Here it needs to unlock because an unaware developer could also do that: var CacheData = accessor.Data; // this is why locking in the constructor is wrong
// it will automatically lock in the above line, but the programmer knows nothing about it
// it will work, because it has the r-lock
// but the update will no longer work, because the r-lock never is released.
// ****** then, next time a w-lock is attempted to take, it will most likely block the entire application ******
// here not do a read-lock - which must be prevented
DoSomethingWith(CacheData.Value1 );
DoSomethingWith(CacheData.Value2 );
// ...
DoSomethingWith(CacheData.ValueN );
// here not do an unlock of the read-lock - which must be prevented as well
// also, if you do proper locking and unlocking, but not in try-finally, it will also explode in your face really quick ideally, it would be possible to entirely deny using accessor.Data without using clause, because if the block is not in a try-finally, then it will screw the entire application up, as the cache will never get refreshed. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
A modifier sealable and unsealable for properties.
So that I can make them ReadOnly AT RUNTIME.
Plus the possiblity to set all properties of a class instance to ReadOnly AT ONCE (at runtime).
And the optional (aka programmer configurable) ability to undo that, should it ever be needed (at runtime).
Basically, like Object.freeze() in JavaScript.
UseCase:
Fetch CacheData from SQL with Dapper: connection.Query("SELECT * FROM config_table");
CacheData.SealAll(); // so no property can accidentally (or intentionally) be modified by the developer
put catchData into a lookup-structure with a ReaderWriterLockSlim
Beta Was this translation helpful? Give feedback.
All reactions