Automatic Non-Deterministic Finalisation

The automatic mechanism cannot be deterministic, because it must rely on on the GC to discover whether the object is referenced or not. At times this behaviour is a show stopper. because temporary “resource leaks” or holding a shared resource locked for slightly longer than necessary might be unacceptable in an application. At others, it’s perfectly acceptable. I will focus on the scenarios where it is.

Any type can override protected Finilize method defined by System.Object to indicate that it required automatic finalisation. However the C# syntax for requesting automatic finalisation on a class A is to implement method ~A(). This method is called finiliser a must be invoked when the object is destroyed.

Incidentally any type can have a finalizer, even the value types. However the finalizer on the value type object will never be invoked.

Continue reading “Automatic Non-Deterministic Finalisation”

Advertisements

WCF Protection Level

WCF has a huge security component to it and encrypts and signs messages by default. It could be an overkill especially if you are debugging or transporting data using a secured channel and are trying to squeeze out every bit of performance.

WCFSecurity

To avoid this, you can just implement integrity when confidentiality is not a requirement. In such cases, WCF provides the facility to set the protection level on the message. Also note that protection levels can only be set for messages. WCF does not allow the disabling of protection levels for transport security. The following application file snippet illustrates how to achieve this using configuration files; the messages are required to be signed only before they are sent:

<bindings>
<wsHttpBinding>
<binding name=”test”>
<security mode=”Message”>
<message defaultProtectionLevel=”Sign”/>
</security>
</binding>
</wsHttpBinding>
</bindings>

You can also specify the protectionLevel property through code at ServiceContract and OperationContract as well. Message exchange patterns (MEPs) determine how the messages are sent from the sender to the receiver. WCF does implement security support for both one-way and request-reply MEPs. However, duplex MEPs are available only in WsDuaHttpBinding, NetTcpBinding, and NetNamedPipeBinding.

Application Domains

Application Domains

An application domain is the run-time unit of isolation in which a .NET program runs. It provides a managed memory boundary, a container for loaded assemblies and application configuration settings, as well as delineating a communication boundary for distributed applications. Each .NET process usually hosts just one application domain: the default domain, created automatically by the CLR when the process starts. It’s also possible — and sometimes useful — to create additional application domains within the same process. This provides isolation while avoiding the overhead and communication complications that arise with having separate processes. It’s useful in scenarios such as load testing and application patching, and in implementing robust error recovery mechanisms.

Application Domain Architecture

In most cases, the processes housing the application domains are created implicitly by the operating system — when the user double-clicks your .NET executable file or starts a Windows service. However, an application domain can also be hosted in other processes such as IIS or in SQL Server through CLR integration. In the case of a simple executable, the process ends when the default application domain finishes executing. With hosts such as IIS or SQL Server, however, the process controls the lifetime, creating and destroying .NET application domains as it sees fit.

Continue reading “Application Domains”

A Use for Partial Classes/Structs

The keyword partial has been with us for a while now. Until recently I couldn’t find a use for partial classes/structs unless some of the code is auto generated and you want to make sure you don’t interfere with auto generated code. That is until recently I have been asked to create a struct representing a local date – a data that is not affected by time-zones and lacks a time component,

To make it as close as a native CLR type I had to implement a bunch of interfaces, ISerializable, IEquitable<T>, IXmlSerializable. In addition it had to implement some explicit and implicit convertions, !=, ==, >=, <=, > and < operators. Soon, what seemed like a simple struct grew into couple of thousands lines of code,

There is nothing preventing you from putting all the code into one big file, however I think I found a more elegant solution – use the partial keyword and split one large LocalDate by either the interface being implemented or things it’s implementing. So I ended up with:

  • LocalDate.ISerializable.cs
  • LocalDate.IEquitable.cs
  • LocalDate.Operations.cs
  • LocalData.Conversions.cs

I have also used one of the Visual Studio plugins to nest all of those files under a single LocalData.cs.

So far I couldn’t come back with a single draw back of such approach. Please let me know if there are any!

C#: Thread Safe Event calls

Sudhanshu's Ode to Code

Hello World,

While working on a multi-threaded Windows service that used events heavily, I did some research on how to trigger events in a thread safe manner. Inevitably, one looks for reference material or books that have the respect of the community and Jeffery Richter’s CLR via C# is one such resource.

The Context

In the chapter on Events (Chapter 11, pg 265 in the eBook), Jeffery summarizes the first 3 steps of how to raise events in a thread safe manner by providing a snippet for an extension method that can do this as such:

The above code is supposed to be an improvement over the following way where one uses a temp variable to store the passed in delegate instance and then compares the temp to null:

The reason why he proposes the code in the extension method over the simpler approach above is that though in theory…

View original post 262 more words

Benchmarking hash functions

lonewolfer

It turns out that for integer hash tables implementations the identity function (f(x)=x) is preferred in most cases. This is a trade-off between speed and desirable properties such as uniform distribution that works well for integers. In essence the speed of attempted lookups is so fast that we can afford the increased number of collisions a naive hash function will give us.

For byte arrays such as strings this is not the case, and instead the opposite is true. Optimising the lookup algorithm is less important, and the properties of the hash function much more so.

To choose a good hash function we need to look at both speed, how quickly the hash is calculated, and how likely collisions are to occur in a given use case. We will start with looking at speed, or data throughput, of some of the most interesting potential candidates.

The benchmark

In this micro-benchmark…

View original post 220 more words

Using .NET Reference Source for debugging

Improvements when debugging .NET Reference Source

Historically since the inception of this effort, Microsoft have published sources and PDBs for every major .NET framework update namely .NET framework 4.0 and 4.5. However these builds would be rendered effectively useless the moment any update to the framework was released, since the binaries on the updated box no longer matched the PDBs that were indexed on the reference source server. Unfortunately the design of the system that they had in place was geared towards doing single and infrequent pushes of sources and symbols out and did not account for the sheer volume of builds and patches that come are produced out of the .NET framework build system.

Continue reading “Using .NET Reference Source for debugging”

Reference types vs value types

All C# types fall into the following categories:

  • Value types
  • Reference types
  • Generic type parameters
  • Pointer types

Value types comprise most built-in types (specifically, all numeric types, the char type, and the bool type) as well as custom struct and enum types.

Reference types comprise all class, array, delegate, and interface types. (This includes the predefined string type.) The fundamental difference between value types and reference types is how they are handled in memory.

Continue reading “Reference types vs value types”

How C# 6.0 Simplifies, Clarifies and Condenses Your Code

C# 6.0 isn’t a radical revolution in C# programming. Unlike the introduction of generics in C# 2.0, C# 3.0 and its groundbreaking way to program collections with LlNQ, or the simplification of asynchronous programming patterns in C# 5.0, C# 6.0 isn’t going to transform development. That said, C# 6.0 will change the way you write C# code in specific scenarios, due to features that are so much more efficient you’ll likely forget there was another way to code them. It introduces new syntax shortcuts, reduces the amount of ceremony on occasion, and ultimately makes writing C# code leaner. In this article I’m going to delve into the details of the new C# 6.0 feature set that make all this possible. Specifically, I’ll focus on the items outlined in the Mind Map shown in Figure 1.

dn879355.Michaelis_Figure1_hires(en-us,MSDN.10)

Continue reading

Blog at WordPress.com.

Up ↑