Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,131 | Comments: 45,568

filter by tags archive

I knew there were reasons for those multi threading warning lists

time to read 2 min | 237 words

One of the warning signs for bad multi threaded code is calling code that you don’t own while holding a lock. I just discovered a bug in NH Prof that is related to just that issue.

But I wasn’t really stupid, and the story of this bug is a pretty interesting one.

Let us look at what happened. I have a deadlock in the application, where two threads are waiting for one another. In the UI thread, I have:


And on a background thread, I have:


This is actually code that happen in two separate classes. And it sounded very strange, until I walked up the stack and found:


All nice and tidy, and it looks good. Except that Sessions.Add invoke the SessionsCollectionChanged, which perform a block UI call, while the UI is trying to enter a lock that is currently being held.

Like I said, this is a classic threading issue, but it is pretty hard to see, unless you can actually get the stack trace.



so the line between 3rd party code and own, but unrelated, code is very blurry. this was an interesting example for that.

Mike Rettig


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

Ayende Rahien


I am. This is a case where I am updating the UI, I had to do something there.

John Chapman

I 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.

Comment preview

Comments have been closed on this topic.


  1. RavenDB Conference 2016–Slides - 4 hours from now
  2. Proposed solution to the low level interview question - about one day from now

There are posts all the way to Jun 02, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats