Always Read the Small Print to Avoid Disappointment!
Implementing Value Types – Best Practices
When implementing you own struct you should take into consideration the following:
- Use structs when you intend to create a great many of them
- structs should be small. Large structs (i.e. structs with many fields) would lead to poor performance, since structs are copied each time.
- Use structs when you require high density memory collections. Structs have have a much simpler memory layout and offer excellent memory density and lack of overhead
- Override structs Equals(…) method and implement IEquitable<T> interface to avoid boxing.
- Overload == and != operators
- Override GetHashCode method.
- structs should almost always be immutable. Actually I’ll go further and say always. Mutable structs could lead to confusion if declared as readonly. Any modifications to a mutable readonly struct will be ignored, making it a very difficult bug to spot.
Structs have also got their own limitations. Since they don’t have an object header, you cannot for example use a lock(…) on a struct since this will result on compile time error. However Monitor.Enter(…) accepts any object, structs included, thus leading to a bug. The value of the struct will be boxed each time and that would be equivalent to having no lock at all!
Troubleshootng Deadlocks in .NET Applications
What do you do when your application become unresponsive due to potential deadlocks?
I think the first thing to do is to identify exactly where the application hangs due to a deadlock. To do this you should replace the lock(…) statement with it’s equivalent Monitor.Enter(…)/Monitor.Exit(…). Monitor has an argument which alloys you to specify timeout. So when you change the suspicious code with Monitor.Enter(…)/Monitor.Exit(…) while specifying the timeout, the code will throw the exception when this timeout has exceeded the specified timeout. While this doesn’t solve the dead lock issue, it points you to the location within you code where there is a possible issue.
Additionally, you need to make sure that the locks are taken in the same order i.e,
lock(_a)
{
lock(_b)
{
....
}
}
This is only for troubleshooting purposes. You should revert back to normal locking when the issue is found and fixed.
One easy thing you can do is to pause execution within Visual Studio by pressing on the pause button and then see what each thread is up to.
You also might want to consider more granular locking primitives, such ReadWriterLockerSlim and refactor you code to use less locking.
Whenever you feel like putting a lock always question yourself if this is the right thing to do and if there is a way doing this without locking all together
C# – Undocumented Keywords
While browsing the code of the interlocked class I stumbled upon the following piece of code
public static T CompareExchange<T>(ref T location1, T value, T comparand) where T : class
{
// _CompareExchange() passes back the value read from location1 via local named 'value'
_CompareExchange(__makeref(location1), __makeref(value), comparand);
return value;
}
Further googling revealed that there are actually 4 undocumented keywords in C# __arglist, __refvalue, __makeref, __reftype
More on the subject can be found on codeproject: http://www.codeproject.com/Articles/38695/UnCommon-C-keywords-A-Look
The C# Memory Model in Theory
The C# memory model makes and shows the code patterns that motivate the guarantees; the second part will detail how the guarantees are achieved on different hardware architectures in the Microsoft .NET Framework 4.5.
One source of complexity in multithreaded programming is that the compiler and the hardware can subtly transform a program’s memory operations in ways that don’t affect the single-threaded behavior, but might affect the multithreaded behavior.
Original:
http://msdn.microsoft.com/en-us/magazine/jj863136.aspx
DateTime – It’s all about the rules!
The Rules
- Calculations and comparisons of DateTime instances are only meaningful when the instances being compared or used are representations of points in time from the same time-zone perspective.
- A developer is responsible for keeping track of time-zone information associated with a DateTime value via some external mechanism. Typically this is accomplished by defining another field or variable that you use to record time-zone information when you store a DateTime value type. This approach (storing the time-zone sense alongside the DateTime value) is the most accurate and allows different developers at different points in a program’s lifecycle to always have a clear understanding of the meaning of a DateTime value. Another common approach is to make it a “rule” in your design that all time values are stored in a specific time-zone context. This approach does not require additional storage to save a user’s view of the time-zone context, but introduces the risk that a time value will be misinterpreted or stored incorrectly down the road by a developer that isn’t aware of the rule.
Uploading file to Google Drive with C# code
I had to host some files on Google Drive and they needed to be updated on regular basis. Going through the GUI is a tedious task if repeated often, so I ended up coding my own upload code.
The upload login is just using the Google SDK, but the tricky part is the authentication with the Google Services, which is OAuth 2.0 ticket base and needs interaction at least for the first run of the program.
Here is the Google Drive encapsulated logic. It exposes methods for listing the drive contents, downloading and uploading:
And here is the application logic. It’s just a command line utility that accepts the client Id and secret as first parameter and the file to be uploaded as third:
And the rest is the most tricky part. The authentication:
Elliot Balynn's Blog 