Synchronization article on developerWorks

Tue Jul 24 21:57:00 GMT 2001

On 2001年7月24日, Boehm, Hans wrote:
> I just tried Tom's program on my Pentium II/300 running RH6.2. I see a
> bigger difference between 3.0 and 3.1. I have some local changes in my
> tree, but I don't think they effect the empty or staticEmpty test.

I noticed the tests vary considerably between runs. Also, the asserts in
natObject.cc are not disabled; that helps a bit.
Dynamic linking incurs some cost that a JIT can probably eliminate.
> 4) Contended synchronization might be handled better. If so linuxthreads
> should really do the same.

Last I checked, linuxthreads didn't spin on a mutex... after one
test_and_set failure it falls into a nanosleep. That may have changed in
newer releases.
I'm curious if the path for reentrant monitors couldn't be shortened
somewhat. In _Jv_MonitorExit we have
 if (__builtin_expect(light_thr_id == self, true))
 {
 count = he -> light_count;
 if (__builtin_expect((address & ~HEAVY) == addr, true))
 {
 if (count != 0)
 {
 // We held the lightweight lock all along. Thus the values
 // we saw for light_thr_id and light_count must have been
 // valid.
 he -> light_count = count - 1;
 return;
No compare_and_swap here. I guess if a thread evaluates "light_thr_id ==
self" true it knows it holds the lock. Why can't _Jv_MonitorEnter do the
same and potentially avoid the CAS? Am I missing something?
Index: natObject.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/lang/natObject.cc,v
retrieving revision 1.17
diff -u -r1.17 natObject.cc

--- natObject.cc 2001年07月23日 03:51:17 1.17
+++ natObject.cc 2001年07月25日 04:46:49
@@ -768,8 +769,8 @@
 assert(!(addr & FLAGS));
 retry:
- if (__builtin_expect(compare_and_swap(&(he -> address),
- 0, addr),true))
+ if (__builtin_expect (he->light_thr_id != self
+ && compare_and_swap(&(he -> address), 0, addr), true))
 {
 assert(he -> light_thr_id == INVALID_THREAD_ID);
 assert(he -> light_count == 0);
