2

Somehow we got a LOT of ReaderWriterLockSlim in our code. Each of them takes 6K memory, so this has become a big issue.

As a quick fix, I'm looking for a less memory-hungry replacement. I'm trying a Joe Duffy's RW-lock, but it's not upgradeable and write-recursive (and is pretty hard to make it such).

Is there any other, more memory-light replacement?

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
Victor Sergienko
  • 13,115
  • 3
  • 57
  • 91
  • 2
    First things first- what are you doing to the RWLS to make them take 6K? Must have an awful lot of pending requests... – Chris Shain Apr 04 '13 at 23:07
  • Why don't you just use the regular ReaderWriterLock? It only requires 44 bytes. – Hans Passant Apr 04 '13 at 23:08
  • @Chris Shain, `ReaderWriterLockSlim` takes it out of the box, IIRC. Unless it's terrified by `LockRecursionPolicy.SupportsRecursion` parameter. – Victor Sergienko Apr 04 '13 at 23:26
  • Also, have you definitively proved that you even need a RWL as opposed to a plain old lock? A RWLS has at least 2x (the old non-slim variation was almost 10x) the overhead so your readers will need to significantly outnumber writers and they will need to hold the lock for an extended time to break even on the penalty. – Brian Gideon Apr 05 '13 at 02:35
  • No, in fact, it's not needed, as the whole component using it is done wrong. But I'm afraid that in short perspective a "don't do that" answer won't help anyway (no offense intended). – Victor Sergienko Apr 05 '13 at 09:55
  • @Hans Passant, thanks, that's close, but it's not recursive. – Victor Sergienko Apr 05 '13 at 12:48
  • ReaderWriterLock is recursive. It is just missing the option to make it not recursive. Which is why it isn't slim. Some sanity might be called for btw, you have a lot of threads to make the slim version grow so large. Saving kilobytes when you use megabytes doesn't make that much sense. – Hans Passant Apr 05 '13 at 13:08
  • Sorry, I didn't consider my current problem carefully enough. It is the answer to my formulation, just more question is more complex: for me, R or W lock from inside write lock in the same thread should be valid - `ReaderWriterLock` won't do it. – Victor Sergienko Apr 05 '13 at 13:19
  • ReaderWriterLock uses the same number of WaitHandles as ReaderWriterLockSlim, I don't think you'll find much of a difference--even if you could accurately measure it. – Peter Ritchie Apr 07 '13 at 23:57

2 Answers2

1

Well, an obvious approach would be to use ReadWriterLock (sans Slim), which I believe is less memory intensive (but also less efficient in some scenarios).

500 - Internal Server Error
  • 28,327
  • 8
  • 59
  • 66
  • It's not recursive - I cannot acquire read lock from inside write lock, or in a more complex scenario. For legacy reasons, I need it to work this way. – Victor Sergienko Apr 05 '13 at 12:49
  • @Victor: `ReaderWriterLock` supports recursion, upgrades from read to write, and downgrades from write to read. If you have the read lock, you can call `UpgradeToWriteLock`. – Jim Mischel Apr 05 '13 at 12:56
  • Sorry, I didn't consider my current problem carefully enough. It is the answer to my formulation, just more question is more complex: for me, R or W lock from inside write lock in the same thread should be valid - `ReaderWriterLock` doesn't accept this. – Victor Sergienko Apr 05 '13 at 13:19
  • Can you back up (via a reference) this claim that it's "less memory intensive"? – Peter Ritchie Apr 07 '13 at 23:57
0

In case someone else needs a memory-lighter RW lock with the same semantics as ReaderWriterLockSlim:

  • upgradeable;
  • recursive;
  • lock belongs to a thread, so, for instance, recursive W-locks are OK, or R-lock from inside W-lock is OK;

the one from Mono source should be OK.

Victor Sergienko
  • 13,115
  • 3
  • 57
  • 91