IGNORE LAST POST; gc not at fault; questions about mutexes vs critical sections

[Adam Megacz <gcj at lists dot megacz dot com>]

Once again, I find myself in the unenviable position of retracting
previous statements. I really need a script to do this for me.

The problem actually had nothing at all to do with GC; rather, it
turns out that synchronization is obscenely, horrendously slow on
win32. Both StringBuffer.toString() and the constructors for the
particular kinds of objects I've been playing with both result in a
synchronization operation.

I'm going to reimplement win32 locking with Critical Sections (no
kernel-user context switch in the common case) instead of Mutexes -- I
can't see a good reason to stick with Mutexes, since GCJ threads never
need to synchronize across a process boundary, and Mutexes are usually
slower.

Does anybody know why Mutexes were chosen over Critical Sections in
the initial win32 implementation? True, Mutexes offer better
performance if many (4+) threads contend on the same lock, but I would
tend to think that good performance in the common case (unlocked
mutex) would be more important than performance in the highly-locked
case.

  - a