What are the most common gotchas of asynchronous programming?
===

We develop backoffice application that historically performs long running operations in UI thread (i.e. single threaded). So we decided to add some parallelism to make aplication more responsive.
But we don't whant to introduce hardly reproducible and detectable bugs and now we geather scenarios of "how not to". Sure it does not guarantee the quality of the app but allows to avoid silly mistakes.

I'd like to add that our team consists of two "fighting" camps.
Some prefer to implement new features for small part of the system thus becoming ware of the pitfalls as they naturally arise. It is a tricky way to combine research and development tasks in one;) (Sometimes it really does well)

Other belong to the second group of so called concervative theoretics who prefer to start with analysis of current system's design, collect the whole bunch of use cases concerning particular task and later define the set of appopriate architectural descisions. Moreover I have the experience of parallel programming and know that overlooking a small detail can cost much in future.=)

A few words about the application:

Many business entities of our app are logically interconnected and so are the UI elements which are very often large lists or trees. Cascades of refreshes can be initiated just by one click. Our present Model considerably worsens the sitution cause it is not thread safe and extensively uses Entity Framework giving us a nice;) chance of deadlocks at server side.

  

