Synchronization article on developerWorks

[Jeff Sturm]

On Thu, 26 Jul 2001, Boehm, Hans wrote:
> I don't think that patch is sufficient, since you also need to check that
> the address corresponds to the object you're looking for.  Even if it is,
> you would neeed to increment the light_count field, unlike the other case.

All of that should be done after the conditional.  My only change was to
short-circuit the CAS.  I'm assuming if this thread sees
he->light_thr_id == self then he->address must not be NULL.

> The harder question is whether the added test is worth it.  I believe the
> rule of thumb in one of the IBM papers was that reentrant locks have about
> 10% of the frequency of initial uncontested locks.  At that rate it's
> probably not worth it.  But I gather those statistics vary for other
> applications.

Good point.  I'd assumed the compare_and_swap is far more expensive than
a simple load and compare.  That's not quite correct; a failed
compare_and_swap may be comparatively fast.

I instrumented the locking functions a little to obtain some rough
numbers for each of three benchmarks.  The first measures a simple monitor
enter/exit loop, the second measures the same loop while the lock is held
by the same thread, and the third measures two threads competing for the
same lock:

                          -- simple ----- reentrant ---- concurrent
Name                      Count   Pct    Count   Pct    Count   Pct
----                      -----   ---    -----   ---    -----   ---
_Jv_ThreadSelf             3666   9.7     3710  15.2     6231   8.1
compare_and_swap          23729  62.8      346   1.4    45408  59.3
compare_and_swap_release   1490   3.9                    3384   4.4
_Jv_MonitorEnter           4518  11.9    11897  49.2     6900   9.0
_Jv_MonitorExit            2885   7.6     6189  25.6     7857  10.3
run                        1521   4.0     2027   8.4     5881   7.7

total                     37810  98.9    24171  98.9    75663  98.9

So compare_and_swap dominates the first and third, but is negligible in
the middle column... not exactly what I expected.  I'm not sure why
_Jv_MonitorEnter goes so high.  Branch misprediction is one possibility.

Jeff