ebdrup

I can see how STM could have some performance implications, I mean if the atomic blocks get large ther is a lot of bookkeeping about what memory has been read and written. I can also see there is a lot of room for smart soultions in reducing the amount of bookkeping nessesary. But I love the power of the concept of transactional memory.

I'm wondering, couldn't STM have been implemented by you inserting the locks nessesary or probably better, a combination of locks where they would be smart and not deadlock and reevaluating where that would be deemed smart. I mean it's easy to think up scenarioes where there would be performance problems with reevaluating and you need a lot of good heuristics to ensure good performance in most cases. If you let the compiler insert the locks nessesary you can have it analyze for deadlocks at least in some cases and you eliminate the problem of having to keep a global order of locks that you talk about in the video.

Why did you opt for reevaluating instead of inserting locks. (guess the answer is composability)

Suppose I have a cache of some calculation, that I calculate in a lock with double checking to be thread safe, like this:

private static readonly Dictionary<Type, int[]> _typeInts = new Dictionary<Type, int[]>();

public int[] TypeInts
{
    get
    {
        Type thisType = this.GetType();
        if (!_typeInts.ContainsKey(thisType))
        {
            lock (_typeInts)
            {
                if (!_typeInts.ContainsKey(thisType))
                {
                    _typeInts[thisType] = <<calculate int[]>>;
                }
            }
        }
        return _typeInts[thisType];
    }
}

Would I be able to replace this with:

private static readonly Dictionary<Type, int[]> _typeInts = new Dictionary<Type, int[]>();

public int[] TypeInts
{
    get
    {
        atomic
        {
            Type thisType = this.GetType();
            if (!_typeInts.ContainsKey(thisType))
            {
                _typeInts[thisType] = <<calculate int[]>>;
            }
        }
        return _typeInts[thisType];
    }
}

my intuition says it should work if I do all looking up and updating of the _typeInts inside an atomic block.
But suppose the ContainsKey is run and another thread interrupts before the int[] is calculated. The other thread runs the same atomic operation to completion, would the first atomic opration retry because some state it read was updated or would it throw an exception when trying to insert a duplicate key?

Great stuff!
I would really like to see more on how you create the actual Entity mappings, when will the beta be availabel for download and when will this ship?

Waht about the drag and drop? MS really needs do do some work on making drag&drop easwy to implement in WinForms applications, is anyone looking at this for Widbey?