http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I don't know that I agree with your warning sign here. I think there are plenty of other areas of interest to discuss before talking about third party code and locks. First, I'm guessing the issue is that the Execute.OnUIThread runs synchronously, meaning it does not return until the item has been executed on the UI thread? I would guess that would be the first warning sign. If that update could be queued up instead (ran asynchronously to the caller, this issue would have been averted). I'm also a proponent of having certain classes run exclusively on the UI thread, (presenter/viewmodel/view), with the back end running on the whatever threads. Whenever code is executed on the presenter/viewmodel/view it is the UI thread (you ensure that through the semantics of your communication between UI and service layer). You then send your data in an immutable fashion to the UI thread such that the need for locking on the UI thread pretty much goes away. The code that is executing is always accessed from a single thread, so all of it's objects are free to touch, and all objects passed to these classes would be immutable (messages really) meaning they too can be accessed without working about locking. That all being said there are a number of lessons to be learned from this example when you abstract out the UI thread part. This same issue can arise even without a UI. Thanks for the story. http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment4http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment4Sat, 19 Sep 2009 17:24:50 GMTMike, I am. This is a case where I am updating the UI, I had to do something there. http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment3http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment3Sat, 19 Sep 2009 11:37:10 GMTOren, Locking on shared state? I thought you were a proponent of message based concurrency. This post demonstrates exactly why concurrency combined with shared state is so hard. Looking forward to your next thread race or deadlock, Mike Rettig http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment2http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment2Sat, 19 Sep 2009 03:39:55 GMTso the line between 3rd party code and own, but unrelated, code is very blurry. this was an interesting example for that. http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment1http://ayende.com/4204/i-knew-there-were-reasons-for-those-multi-threading-warning-lists#comment1Sat, 19 Sep 2009 01:02:19 GMT