Re: lock statement questions
- From: "Jon Skeet [C# MVP]" <skeet@xxxxxxxxx>
- Date: 29 Jun 2006 04:00:50 -0700
Greg Young wrote:
<snip>
Jon Skeet
It also fails as soon as you've got a property which needs to set two
different variables. I prefer to have just one way of obtaining thread-
safety: a lock.
As I had said, I was dealing with a case where we were dealing with
something under reference size (without screwing with alignment etc). I feel
removing the needless locking is important in performant areas of code.
How often have you come across code where the locking was the
performance hit? I've only done so *once* - and that was when writing
lock primitives myself.
I'll take the balance of consistency (only needing one way of achieving
thread safety) over a *possible* performance hit until that performance
hit is *proven* to be a bottleneck. I believe the number of
applications where it's an issue is vanishingly small.
Just to be clear .. I agree that volatility is a valid concern; I just think
that using lock to provide it is bad practice as it comes with significant
overhead (in the range of 100 times slower) and works as a by product of the
optimizer not inlining (see previous post for inlining)
I believe in simplicity/consistency over performance - it's easier to
refactor to performance than the other way round. I'm a *big* fan of
not micro-optimising.
Jon
.
- References:
- lock statement questions
- From: djc
- Re: lock statement questions
- From: Greg Young
- Re: lock statement questions
- From: Jon Skeet [C# MVP]
- Re: lock statement questions
- From: Greg Young
- Re: lock statement questions
- From: William Stacey [MVP]
- Re: lock statement questions
- From: Greg Young
- lock statement questions
- Prev by Date: Re: Counterpart of the 'synchronized' java keyword?
- Next by Date: Re: Philosophical question about separating tiers
- Previous by thread: Re: lock statement questions
- Next by thread: Re: lock statement questions
- Index(es):
Relevant Pages
|