Mutable value types: the good, the bad and the ugly

Mutable value types: the good, the bad and the ugly | ASP NET Hosting

Mutable value types: the good, the bad and the ugly | ASP NET Hosting — Thu, 07 May 2009 03:00:35 GMT

PingBack from http://asp-net-hosting.simplynetdev.com/mutable-value-types-the-good-the-bad-and-the-ugly/

Mutable value types: the good, the bad and the ugly | Microsoft Share Point

Mutable value types: the good, the bad and the ugly | Microsoft Share Point — Thu, 07 May 2009 03:26:15 GMT

PingBack from http://microsoft-sharepoint.simplynetdev.com/mutable-value-types-the-good-the-bad-and-the-ugly/

re: Mutable value types: the good, the bad and the ugly

stic — Thu, 07 May 2009 09:01:26 GMT

hi,

maybe the 'SafeSpinLock' is a good candidate for a class that will become a part of .net framework?

just in case that we will have 100+ different discussions out there how to implement it: initialise it, dispose in controlled manner, pass around, etc..

re: Mutable value types: the good, the bad and the ugly

Nick — Thu, 07 May 2009 15:26:32 GMT

Why not just use the already present Nullable<T> wrapper?

SpinLock? spinWrapper;

done :)

re: Mutable value types: the good, the bad and the ugly

Lucas — Thu, 07 May 2009 18:11:57 GMT

@Nick, Nullable<T> is still a value type (struct) with copy-by-value semantics, not a reference type, like the sample wrapper class.

re: Mutable value types: the good, the bad and the ugly

commongenius — Tue, 19 May 2009 03:25:47 GMT

Its interesting that you reference a post from Eric Lippert's blog. Eric has written quite a few blog posts about the importance of choosing value versus reference types based on their semantics, not their implementation. The fact that value types are allocated inline and reference types in their own space on the heap is an implementation detail that should be irrelevant to the design of the type. Performance characteristics change with time and environment, but type semantics are fixed. I am curious why you felt it was necessary to break this rule of design for types like SpinLock and SpinWait.

re: Mutable value types: the good, the bad and the ugly

phillips.joshua — Thu, 04 Jun 2009 02:39:45 GMT

commongenius,

Apologies for the slow response. You're concern is quite valid and I assure you we spent a lot of time debating the tradeoffs before we came to a decision.

Ultimately, while we try our best to avoid implementation details there are just some scenarios that we wouldn't have been able to enable if our types required object allocations. When it comes down to it, we felt that our target audience would often throw aside the types we provided and build their own value-type versions that would give them the performance they need. Of course, we introduce new issues, such as the ones described in this post but we think the developers that would use these types are willing to overcome those issues if it meant they didn't need to build their own types from scratch.

Josh

re: Mutable value types: the good, the bad and the ugly

Abhijeet Patel — Sun, 05 Jul 2009 22:13:05 GMT

Josh-

Since value types are typically alive as long as the stack frame on which they are allocated is active(i.e the stack frame the currently executing thread is running on) and are de-allocated(or fall out of scope) when the stack goes away.

What is the lifetime of a value type(such as SpinLock )when it's wrapped by a reference type(such as SafeSpinLock), are lifetimes of value types the same as the lifetime of the enclosing reference type in this case?

re: Mutable value types: the good, the bad and the ugly

Abhijeet Patel — Sun, 05 Jul 2009 22:49:31 GMT

Josh-

"when we retrieve a partition lock via List’s indexer, we actually get a new copy of a SpinLock "

why would indexing into a List<T> give you a new value type. value types are not boxed when using List<T>

Also, I ran the following and I noticed that I get the same hashcode for all SpinLocks, can you shed some light on why this is so?

List<SpinLock> list = new List<SpinLock>();

var sl1 = new SpinLock();

var sl2 = new SpinLock();

var sl3 = new SpinLock();

Console.WriteLine(string.Format("Item1 Hashcode {0}",sl1.GetHashCode()));

Console.WriteLine(string.Format("Item2 Hashcode {0}", sl2.GetHashCode()));

Console.WriteLine(string.Format("Item3 Hashcode {0}", sl3.GetHashCode()));

Console.WriteLine("\n");

list.Add(sl1);

list.Add(sl2);

list.Add(sl3);

ThreadPool.QueueUserWorkItem(_ =>

{

var str = string.Format("ThreadID:{0} reading item at index 0,hashcode{1}", Thread.CurrentThread.ManagedThreadId, list[0].GetHashCode());

Console.WriteLine(str);

}

);

ThreadPool.QueueUserWorkItem(_ =>

{

var str = string.Format("ThreadID:{0} reading item at index 1,hashcode{1}", Thread.CurrentThread.ManagedThreadId, list[1].GetHashCode());

Console.WriteLine(str);

}

);

ThreadPool.QueueUserWorkItem(_ =>

{

var str = string.Format("ThreadID:{0} reading item at index 2,hashcode{1}", Thread.CurrentThread.ManagedThreadId, list[2].GetHashCode());

Console.WriteLine(str);

}

);

//list.ForEach( i=> Console.WriteLine(i.GetHashCode()));

Console.Read();

--------

Output:

Item1 Hashcode -1863199827

Item2 Hashcode -1863199827

Item3 Hashcode -1863199827

ThreadID:3 reading item at index 0,

hashcode -1863199827

ThreadID:4 reading item at index 1,

hashcode -1863199827

ThreadID:3 reading item at index 2,

hashcode -1863199827

re: Mutable value types: the good, the bad and the ugly

phillips.joshua — Tue, 07 Jul 2009 03:53:53 GMT

Hi Abhijeet,

Yes, when you box a value type, they become stored on the heap and, thus, have the same lifetime as the garbage-collected wrapper.

Regarding List's indexer: It is because the value types are not boxed that a new copy is given out every time. If the value-types were boxed, they would be wrapped in a reference and that same reference would be passed out of the indexer on each access.

Regarding hash codes: See the documentation for Object.GetHashCode. "The default implementation of the GetHashCode method does not guarantee unique return values for different objects." In fact, for some structs in the BCL, even the overriden GetHashCode function does not return unique values for different objects (try it on Int32). For SpinLock, we chose not to override the default GetHashCode and provide an accurate hashing function simply because we don't want to encourage people to use them like classes and pass them around. Hash functions are typically used to store objects in structures like hash tables, and since that's a bad practice for the reasons listed in this post, we don't want to send mixed signals by actually implementing the method.

Thanks for the questions! Hope that helps.

Josh

re: Mutable value types: the good, the bad and the ugly

Abhijeet Patel — Tue, 07 Jul 2009 09:23:07 GMT

Thanks for responding.

I see what you mean,so unless there were a way to pass a reference to the SpinLock contained "inside" the List<SpinLock>, you would always get a copy when you index, and hence the bug.

Just a thought...if the SpinLock struct implemented an ISpinLock and you had a List<ISpinLock>, you would be able to access the same SpinLock instance via the interface?