Re: CSingleLock - known behaviour?

See below...
On Sat, 28 Jun 2008 11:36:42 -0700 (PDT), neilsolent <neil@xxxxxxxxxxxxxxxxxxxxxx> wrote:



Joseph M. Newcomer wrote:

You are confusing correctness with performance.

Am I? I didn't know that. Thanks.
****
It seems obvious.
****

If you are having collisions in a critical section at the rate of thousands per second,
there is something deeply wrong with the design of your code.

NO I am not. I am gving you "what ifs". Write code that works under
all circumstances - it's easy to do.
****
It is better to design code that doesn't require locking. That way you KNOW it is going
to work "under all circumstances" because there is no way to accidentally create
circumstances in the future under which it won't work (the most common failure mode of
synchronization with multiple locks is that it is fragile under maintenance)
****

You should not be trying to
synchronize anything that has such a high collision potential. And how is locking it 20
times if all the locking conditions are met "more efficient" than locking it once if no
conditions are met?

Because the lock could be blocked by another thread, for a random
amount of time. If you don't need the resource, don't lock it.
****
If the time is more than a few microseconds, you shouldn't be locking at all. You should
be redesigning
****

You are talking nonsense here, because you are talking about
preoptimzing in the absence of any measured performance data.

Am I? Sorry once again.
****
Yep. Definitely. Building complex solutions based on hypotheticals and opinion, as
opposed to building simple solutions that rely on neither, is a losing development
strategy. There are three approaches
Don't build systems that require synchronization
Don't build systems that preoptimize locking strategies at the risk of correctness
Don't build systems that are complex unless you can prove the complexity is
justified

You are violating all of the above.
****

If most of the conditions
are true most of the time, your "more efficient" implementation is in fact LESS efficient!
I always get suspicious of people who start talking about efficiency before they start
talking about measurement of performance or models of performance.

Well your code will hang one thread unneccessarily for 18 months, if
the other blocks the resource for that long :-). Mine doesn't do this.
****
No, my code won't hang at all, because I wouldn't build code that required synchronization
at levels beyond a microsecond or so, and if I use it at all, my goal is < 100ns per lock,
and mostly I would try for < 20ns per lock. That's about enough time to link or unlink an
object from a shared list.
****

In your case, the
worst-case scenario is not just a little bit less efficient, but potentially orders of
magnitude less efficient, than locking once. In addition, if your critical section is
locked thousands of times per second, you should start questioning the design.

No it isn't, I was providing worst case scenarios.
*****
Worst-case scenario: the first if-statement locks the lock and the remaining 20
if-statements are false. Same performance as locking once, far worse performance than
locking each time. If you care about performance, you will not only delay setting the
lock until it is needed, you will unlock it immediately. Therefore, there is no need to
lock it multiple times because each lock sequence is completely isolated from every other
locking sequence.
****

Here is a good rule to remember: optimizing lines of code (your approach) will buy you
single-digit-percentage performance improvements. Optimizing architecture (such as not
locking in the inner part of a loop) will buy you orders of magnitude performance
improvement. I spent 15 years doing performance measurement, and there were no exceptions
to this rule (which I developed empirically by seeing what happened when people tried to
pre-optimize their code without gathering performance data or studying the program
architecture). You are pre-optimizing lines of code, and that is fundamentally wrong at
this point. You do not optimize lines of code until you know where the expensive lines of
code are.

Sorry once again.
****
I developed another principle doing performance analysis: "Ask a programmer where the
performance bottleneck is in their code, and you will get a wrong answer. Not just a
little bit wrong; wrong by orders of magnitude". This rule was 100% true, all the time,
in every situation. Including my own code, when I measured it. So I have learned to
ALWAYS distrust *opinions* of where there are performance problems, because I know they
are always wrong.

The classic example was always the programmer who completely redesigned their algorithm
for "efficiency". The resulting code was sometimes SLOWER than the original code, but
when it was faster, it was provably faster. We could see it in the numbers. Instead of
accounting for 0.05% of the total time used in the program, it now accounted for 0.025% of
the total time. There was usually some glaring design error (in retrospect) that
accounted for 30% of the time, Another that consumed 10% of the time, another that
consumed 5% of the time, and every once in a while, one that cost an order of magnitude
performance. None of these could be fixed by tweaking lines of code at the level you are
concerned about.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.