4 ms·

Interesting. I have to be honest I did not know about the whole reader/writer lock support. I was accustomed to just using the "lock" keyword.

bananas 13y ago
Watch out for ReaderWriterLockSlim. It's dangerous under certain circumstances particularly if: 1. You have one core or two cores. 2. Your CPU load is high. 3. Your thread pool is pretty heavily utilised so there is a queue building up (think IIS). It relies on spinlock so it enters a tight loop for a number of cycles to avoid lock contention. At this point it increases the CPU load so every thread ends up getting blocked on spinlocks. This means you end up with N runnable threads (one per core) which are utilising 100% CPU in a tight loop and your site goes down. I wouldn't rely on it for a concurrency mechanism in production! We've had this in production and it took us out for a few hours. Note: the root cause was a for loop that never terminated but all the other threads went batshit at 100% inside ReaderWriterLockSlim so it's impossible to identify what is going on. You can't even log into a box under that load so it's a case of waiting for it to blow and dropping a minidump out with process explorer and getting that off-site and firing it up in VS. Total nightmare.
- josteink 13y ago
  > Watch out for ReaderWriterLockSlim. Yes. And if you register this in a using-statement thinking it will be disposed, you may encounter a edge case where the lock has been created, but not assigned and thus wont get disposed and you will have orphaned locks jamming up your system. Where I worked, we had complete system crashes which could be traced back to "incorrect" usage of this very class[1]. It only happened in production, it was hell to debug, and we had to use more low-level tools than I ever thought should be needed for .NET code. We replaced it with a traditional lock {} and never looked back. [1] "Incorrect" as in not having around 50 lines of boilerplate which has to be tediously and 100% correctly done, on a per lock-invocation basis, since generalizing the implementation will ruin its correctness.
  - Pxtl 13y ago
    > Where I worked, we had complete system crashes which could be traced back "incorrect" usage of this very class Ah, yes. The ultimate abstraction failure - a bad library is one that requires you not only understand its abstraction, but you understand its implementation and the underlying layer in such meticulous detail that you could re-write the entire thing from scratch. See also webforms. Worse than useless.
- danesparza 13y ago
  Here is a gem on SO about ReaderWriterLockSlim: http://stackoverflow.com/a/17296055/19020 http://stackoverflow.com/a/17296055/19020 HC SVNT DRACONES
  - aashishkoirala 13y ago
    Hey, thanks for that. That is enlightening.
  - bananas 13y ago
    That's marvellous - thanks for posting :)
  - Pxtl 13y ago
    "I have to admit it has way too many bells and whistles" That just described half the objects in the .NET framework for me.

bananas 13y ago

Watch out for ReaderWriterLockSlim. It's dangerous under certain circumstances particularly if: 1. You have one core or two cores. 2. Your CPU load is high. 3. Your thread pool is pretty heavily utilised so there is a queue building up (think IIS). It relies on spinlock so it enters a tight loop for a number of cycles to avoid lock contention. At this point it increases the CPU load so every thread ends up getting blocked on spinlocks. This means you end up with N runnable threads (one per core) which are utilising 100% CPU in a tight loop and your site goes down. I wouldn't rely on it for a concurrency mechanism in production! We've had this in production and it took us out for a few hours. Note: the root cause was a for loop that never terminated but all the other threads went batshit at 100% inside ReaderWriterLockSlim so it's impossible to identify what is going on. You can't even log into a box under that load so it's a case of waiting for it to blow and dropping a minidump out with process explorer and getting that off-site and firing it up in VS. Total nightmare.

josteink 13y ago
> Watch out for ReaderWriterLockSlim. Yes. And if you register this in a using-statement thinking it will be disposed, you may encounter a edge case where the lock has been created, but not assigned and thus wont get disposed and you will have orphaned locks jamming up your system. Where I worked, we had complete system crashes which could be traced back to "incorrect" usage of this very class[1]. It only happened in production, it was hell to debug, and we had to use more low-level tools than I ever thought should be needed for .NET code. We replaced it with a traditional lock {} and never looked back. [1] "Incorrect" as in not having around 50 lines of boilerplate which has to be tediously and 100% correctly done, on a per lock-invocation basis, since generalizing the implementation will ruin its correctness.
- Pxtl 13y ago
  > Where I worked, we had complete system crashes which could be traced back "incorrect" usage of this very class Ah, yes. The ultimate abstraction failure - a bad library is one that requires you not only understand its abstraction, but you understand its implementation and the underlying layer in such meticulous detail that you could re-write the entire thing from scratch. See also webforms. Worse than useless.
danesparza 13y ago
Here is a gem on SO about ReaderWriterLockSlim: http://stackoverflow.com/a/17296055/19020 http://stackoverflow.com/a/17296055/19020 HC SVNT DRACONES
- aashishkoirala 13y ago
  Hey, thanks for that. That is enlightening.
- bananas 13y ago
  That's marvellous - thanks for posting :)
- Pxtl 13y ago
  "I have to admit it has way too many bells and whistles" That just described half the objects in the .NET framework for me.