That is pretty much what happened last night. Here's something to consider....for the longest time I used NOLOCK for different scenarios, and while I never got that particular error, it does lead to result sets that might reflect incomplete update scenarios posted by others.
A few years ago I started using the snapshot isolation level and it took care of some issues. The Snapshot isolation level gives you the best features of a dirty read and a read committed (no locking and no concurrency issues) without the bad side-effects ( incomplete results and lockouts...and in your case, the error you received).
It comes in 2 flavors...a "static" snapshot and a more dynamic type (READ COMMITTED snapshot).
It's not something to rush into - I had to experiment with it for a long time before I truly felt comfortable with it and truly understood how it affects tempdb. It's not for everyone, but it's something to at least be aware of.
.
