[This item captures a discussion with Roger Alsing at http://entityframework.codeplex.com/workitem/120 about adding async support on EF]
On one hand, our async design addresses async requirements but not concurrency requirements, i.e. we still do not support a context to be accessed from multiple threads.
On the other hand, the new Task-based async pattern makes it easier than ever to write code that introduces concurrency on a context: All you need to do is skip awaiting on a Task before you start a new Task on the same context.
This can easily lead to folks to accidentally corrupt state in the context or in their POCO classes. In most cases this bug in user code can be detected early if we monitor Task initiation and we throw any time concurrent Tasks are created.
It would also be important to identifying any actions that are safe to perform concurrently and not throw in those cases. Customers can write (and have in the past written) code that reads state from the context concurrently or executes non-tracking queries concurrently. As long as these are safe things to do, we should not prevent them from working.
It's not possible to throw in all cases where the returned task isn't awaited on, but it should be possible to throw a useful exception when this could actually lead to state corruption.
On one hand, our async design addresses async requirements but not concurrency requirements, i.e. we still do not support a context to be accessed from multiple threads.
On the other hand, the new Task-based async pattern makes it easier than ever to write code that introduces concurrency on a context: All you need to do is skip awaiting on a Task before you start a new Task on the same context.
This can easily lead to folks to accidentally corrupt state in the context or in their POCO classes. In most cases this bug in user code can be detected early if we monitor Task initiation and we throw any time concurrent Tasks are created.
It would also be important to identifying any actions that are safe to perform concurrently and not throw in those cases. Customers can write (and have in the past written) code that reads state from the context concurrently or executes non-tracking queries concurrently. As long as these are safe things to do, we should not prevent them from working.
It's not possible to throw in all cases where the returned task isn't awaited on, but it should be possible to throw a useful exception when this could actually lead to state corruption.