lock() should be employing a low-level critical section which is only a few
machine instructions and should have minimal overhead -- less than a Monitor
or Mutex object. In any case though, if you need lock() et. al . to ensure
the proper functioning of your class, then you need it -- if you don't then
you don't -- it doesn't really seem to be an option if you're telling user
it can be used in a threaded environment. With that said, I'd be surprsised
if any overhead is even measureable in a non-contrived use of your class.
(You could always put the locks in a #def and try w/ and w/o them...)
"Jon Davis" <jo*@REMOVE.ME. PLEASE.jondavis .net> wrote in message
news:uG******** ******@TK2MSFTN GP09.phx.gbl...
Does anyone know if there is any kind of known / published overhead with
using the lock statement (to lock an object to the current thread)? I am
preparing to use it in several object property gets, but I don't want to
use it if it will take a hit on performance.
Thanks,
Jon