Category: .Net Stuff

WindowsIdentity is IDisposable.

Recently I went on a quest to dispose of IDisposable objects wherever I could find them, since many types are IDisposable but people are not aware of this fact. (Suggestion for VS2010, shade types which are IDisposable a different color in the IDE.)

WindowsIdentity.GetCurrent() returns an instance which you should dispose, otherwise you temporarily leak a user handle. (Its a safehandle so its not a huge deal).
Infact, most times you use WindowsIdentity it is good to dispose of the item. Except for one case.

If you call Impersonate() on a WindowsIdentity instance, disposing it will cause hard to diagnose crashes.

It took me a while to work out why, so I thought I would write this up, maybe it’ll save someone else out there the trouble once.

Reflecting through windows identity related code, tokens get duplicated and new WindowsIdentity instances get created all over the place, so it would seem that you were safe to dispose.
However, when you call Impersonate, the WindowsIdentity instance, and its internal safe handle, get stuffed into the current security context, without being copied or duplicated. I don’t know whether that security context disposes the instance later (looks like it doesn’t), but it effectively takes ownership of it, so you can’t.

If you do dispose of it, and you start a timer or queue a work item before the impersonation is undone, when that timer or work item is executed, the .net framework attempts to set up the security context by impersonating again, but the safe handle is already disposed.

As a bonus, you can disable security support in the .Net runtime, in which case the newly corrected code temporarily leaks handles without the runtime being responsible for the leak.

So I have had a chance to look at the CTP briefly and I’ve found a few things of interest

1. There are currently breaking changes, and .Net 4 installs side by side with .net 3.5 much like 1.1 does with 2.0. (Array.Sort method change from the .Net 3.5 beta is back.)
2. BigInteger is now public and in System rather than System.Core
3. System.Core has a few command line app tools, including a command line parser.
4. With the dispose pattern it is no longer considered bad to have Dispose being virtual.
5. Code contract support, I believe the compiler is allowed to optimize based on assertions made using code contracts.
6. AggregateException, an exception containing multiple exceptions. Useful for parallel or pseduo parallel task execution.
7. Concurrent data structures, several of them.
8. Parallel task library integrated into mscorlib
9. A couple of helper classes for common multithread tasks. LazyInit/WriteOnce.
10. Monitor now has methods which use ref parameter for lock taken rather than return value. This allows for reliable lock release, which was previously impossible since an asynchronous exception could occur inside Monitor.TryEnter. Additionally Monitor.Enter also allows for the scenario where an asynchronous exception is thrown during its execution, and has a ref lock taken parameter as well.
11. ManualResetEventSlim, SemaphoreSlim – cheaper non-named synchronization control objects.
12. SpinWait/SpinLock
13. Barrier, a multiple worker thread synchronization structure.
14. Supported platforms attribute, platforms enumeration includes unix, mac, winCE and xbox(?!?) as well as 3 types of win32.
15. Some attributes and reflection stuff for improved com interop capabilities without requiring interop assemblies. This includes a magical feature where two seperate interfaces can be identified as being the same interface and the runtime magically pretends they are the same internally, as much as it can.

I haven’t really played arround with c# 4 yet, so I haven’t discovered any cool new syntax. (Although I’ve heard about dynamic, and generic variance.)

Also i’ve really only looked at mscorlib and system. System.Core was a brief eyeball in reflector, everything else I’ve not had a chance to examine.

A new release of TMD.Algo can be found here.

I’ve added a bunch of stuff since last time, and its even got a few more test cases.

It still needs a bunch more really, but time flies.

If anyone out there uses this thing, I strongly recommend against using the BigInteger hack I added today. Either wait for .Net ~4 when its really available, or grab the mono library. I’m not really sure why I decided to add BigInteger support this way.

Same caveats apply as before, I shipped it without the signing key but without modifying the solution.

Tommorrow is the Google code jam regional onsites, so I’m off to a fun filled day in the city, so to speak.

TMD.Algo 0.0.2.0 finally escaped.

You can get it here.

There is a bunch of new stuff, however not all of it has been tested yet, so as usual use with caution.

The graph class is especially ultra-alpha right now.

One final note, this is a source code and binary release, but it won’t actually compile out of the box.
If you want to make it compile there are several things to do.

1. Create a private key to sign your custom builds (or remove the key signing).
2. Update the InternalsVisibleTo on TMD.Algo so the test cases can see the ugly internal methods.
3. Install NUnit 2.4.8 (or maybe a more recent version will work).
4. Install FxCop 1.36 into the default location (or modify the post build step for TMD.Algo).

Hopefully that should cover it, I haven’t actually tried the steps myself.

I noticed the following method while on a journey through reflector the other day.

RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter(Type otherType)

Quite an odd method really.

Example in use:
GenericEqualityComparer.TypeHandle.
CreateInstanceForAnotherGenericParameter(typeof(T));

This lets you make a GenericEqualityComparer<T> instance.

First thought is why wouldn’t you write
new GenericEqualityComparer<T>()
?

As it turns out its because GenericEqualityComparer has a restriction which says T : IEquatable and the current generic type calling this code has no restriction on T.

So this method is really useful. It allows you to write a set of if statements checking what T implements and then defer processing to appropriate special case generics.

Unfortunately the above method is internal, so you would have to do the equivelent with a bunch of reflection, probably a bit slower too.

I am thinking that we should petition Microsoft to provide a language construct which is syntactic sugar for this method.

var v = new GenericEqualityComparer<T>() : where T is IEquatable;
Could throw an InvalidOperationException if you haven’t guarded for the case where T is not IEquatable;

In other news 0.0.2.0 of TMD.Algo should be out soon, I have a dequeue, a couple more sorts (really basic ones) and an alternative Heap which supports O(1) Contains, and O(log n) Remove at the expense of some extra book keeping. Useful for implementing Prim’s algorithm as the key reduction step can be done in O (log n) (as needed) by simply removing the entry and adding the new one after changing the key.

Licensed under BSD …

TMD.Algo 0.0.1.0 pre-alpha has been uploaded to here

I’ve got a few basics there now, standard sorts and selects and a Heap, as well as the previously mentioned TreeList.

Do not consider any of the API remotely stable at the current time.

Its been a while, but I plan a couple of posts.

Firstly, I was recently reminded of a .Net ‘trick’ I learnt from a friend. We recently took this trick to a new level of ‘evil’.

Strings are immutable right… well sort of.

string a = “a”;
GCHandle handle = GCHandle.Alloc(a, GCHandleType.Pinned);
char[] newString = new char[] {‘b’};
Marshal.Copy(newString, 0, handle.AddrOfPinnedObject(), 1);
Console.Out.WriteLine(a);
Console.ReadKey();

This program outputs the character b. All without actually using the unsafe keyword. The unsafe APIs already exist there to use. (They all have unmanaged permission link demand on them.)

Taking things to the next level however, allows for a bit of fun.

Examples include:
Environment.NewLine, change it to any two characters of your choice.
Exception messages, cause it once, change it and from then on it says whatever you like.

With a bit of reflection however, you can do alot of damage. For instance, change every string which can be found by walking the object hierarchy starting from static fields.

Ahh, hashcodes … such wonderful things.

I was recently reminded of how poorly they are used, and then further reminded of how poorly they are used when I then subsequently used them incorrectly while trying to fix the issue. Which lead me on a hunt, for the perfect hashcode combiner function.

I quickly discovered that there are several categories of hashcode combination:

• Hash codes for structured objects or ordered lists.
• Hash codes for a set of objects (no duplication).
• Hash codes for unordered lists (which contain duplication).

So, for the first case theres a large variety of possibilities to consider. The System.Web assembly contains an internal class which combines hash codes using ((a<<5)+a)^b - which is simply (33*a)^b a rather vague looking formula which is somewhat reminiscent of a*x+b mod c - congruential random number generators. In this case the mod is 2^32, which isn't prime - but at least its very very fast to calculate ;) - all in all this is an acceptable method of combining hashcodes - it doesn't suffer from the pure xor aproach's primary defect which is that if a==b the output is always 0, its fast at 3 single clock cycle instructions required, but it doesn't do all that much to compensate for bad quality input hashcodes. Both of the other two circumstances are unordered which means the hash code combiner function f(a,b) must satisfy f(a,b)==f(b,a). But further more it must satisfy f(f(a,b),c)==f(a, f(b,c)). This second condition is quite restrictive. If additionally we decide that each possible output must occur the same number of times (that is, the hashcode function isn't biased) the possibilities for the function are very restricted. For the domain of 2bit numbers there exists 2^32 functions which take two parameters. Only 16 of these satisfy the reordering and non-biased requirements. Note that I distinguished between sets and unordered lists. My primary reasoning here is that for sets, xor is pretty much perfect, the a==b case where two of the hash codes which are provided are the same only occurs during a hash-code collision in the input which is much rarer than in the unordered list with deliberate duplicates. XOR is a single clock cycle instruction, which means you won't get a hashcode faster. So as long as your input hashcodes aren't too bad, XOR is probably your best choice for calculating the hashcode of a set. This leaves the unordered list case - much more evil I tell you. My search for the perfect unordered list hashcode combiner continues, but I thought I might share some bits of research I've found along the way. Given two inputs a and b which are n-bit numbers - you can break them into n 1-bit pairs a1 b1 a2 b2 ..., where no reordering has occured, the most significant bit of a is paired with the most significant bit of b. There exists unordered hashcode combination functions which can work on groups of these 1-bit pairs. If a function operates on a single 1-bit pair, we shall call that a 1 bit combiner function, if it operates on 2 1-bit pairs then we shall call it a 2-bit combiner function. Some 2-bit combiner functions are actually just 2 1-bit combiner functions applied to each bit, but the majority are more complex. Given the concept of breaking things down, you can construct your own hashcode function for n-bits by grouping the n-bits into 1,2,3,... bit ordered lists and applying 1,2,3...bit combiner functions of your choice to each clump. With that introduction done. 1bit combiner functions: There are only 2 which satisfy all the requirements.

• XOR
• NOT XOR

2-bit combiner functions: There are 16 which satisfy all the requirements, if you consider order of the 1-bit pairs, important. If you don’t there are less.
First are the ones based off the 1-bit combiner functions.

• XOR, XOR
• XOR, NXOR – this can be reversed by changing order of bits.
• NXOR, NXOR

The rest are new.

• 2 bit unsigned addition ignoring overflow – upside down addition can be performed by changing order of bits.
• 2 bit unsigned addition ignoring overflow + 1,2,3 – offset isn’t actualy very useful, but it does change the output – upside down addition can be performed by changing order ofbits.

I don’t have a name for the final type of operator – changing order of bits doesn’t do anything because its symmetrical. It can be xor’d with 1 or 2 or 3. The basic gist however is if one of the arguments is 0 or 3 it behaves like XOR, otherwise it behaves like equality, returns 3 if inputs are the same, 0 if inputs are different. If the inputs are a and b and aRot is input a with its bits switched and bRot is input b with its bits switched then logically the formula is as follows. I am hoping this can be reduced, but right now, thats beyond my puny little brain.

((~(a ^ aRot) | ~(b ^ bRot)) & (a ^ b)) | (((a ^ aRot) & (b ^ bRot)) & (a ^ bRot | b ^ aRot)) – the final b ^ aRot term is unneeded, as it has the same result as a ^bRot in that context, but its included to make the symmetry obvious.

3 bit combinators I haven’t even started on, but I’m sure there is a wealth of complex forms to be found above all the possible combinations of 1 and 2 bit combinators.