Re: race on multi-processor solaris

From: Jonathan Adams (jonathan-ggl_at_ofb.net)
Date: 11/28/03


Date: 27 Nov 2003 21:21:48 -0800

Joe Seigh <jseigh_01@xemaps.com> wrote in message news:<3FC0D7D2.AC654F65@xemaps.com>...
> Jonathan Adams wrote:
> >
> > "SenderX" <xxx@xxx.xxx> wrote in message news:<Q5Vsb.144191$ao4.460450@attbi_s51>...
> > > A lock-free algo has also helped Java scale a lot more:
> > >
> > > http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html#8
> >
> > From that link:
> > > An example of such improvement was to make system dictionary reads
> > > lock-free.
> > >...
> > > It helps a lot for calls like Class.forName(), which do lookups into this data
> > > structure at the lowest level. Before this change, both readers and writers
> > > took out a lock to look at the system dictionary.
> >
> > Having a heavily accessed large dictionary protected by a single lock
> > is a scalability disaster. From their description, they replaced a reader-
> > writer lock with a writer-only lock + lock-free reads, presumably
> > because they only delete from the table at safe points. They didn't have
> > to add the use of CAS, garbage collection, or any of the techniques used
> > in more complicated lock-free algorithms.
>
> Well, Java has garbage collection built in, so I'm not suprised that they
> did not have to add garbage collection. But actually they are adding CAS
> to Java with JSR 166 specifically for high performance lock-free algorithms
> particularly in situations where the built-in GC for Java cannot keep
> up with object reclaimation.

I was just talking about the particular case the original poster mentioned. I
don't pretend to know much about the current state of Java.

> > Solaris scales to hundreds of processors with scant reliance on lock-free
> > algorithms (they are mostly used for async-safety). You can see exactly
> > how much contention there is in a Solaris system using lockstat(1M).
> > Typically, it's not much -- that's one of the big reasons it scales.
>
> SMP w/ uniform memory access?

Generally, though some of the more recent machines have had some
NUMA-ish characteristics that Solaris has started to optimize for.

> > Are there large-scale systems that rely exclusively on lock-free
> > algorithms for consistancy and scalability? Especially the more
> > complicated algorithms?
>
> Not exclusively, I don't think that possible at this point. Sun's done
> a bit of research into this area and filed a number of hw patents in this
> area. You might at some point have to take Solaris off the list of OS's
> that do not rely on lock-free for performance and scalability.

Keep in mind that there is a large difference between Sun Labs and the
Solaris engineering group. The papers I've read on lock free algorithms
don't lead me to think that they are really ready for prime time, in terms
of both complexity and performance gain -- in particular, the fact that
there is little performance gain in the uncontended behavior and a huge
complexity bill to handle the contended case. Most locks simply don't
experience contention, in a well-designed system.



Relevant Pages

  • Re: Why "lock" functionality is introduced for all the objects?
    ... very nature of objects in Java. ... synchronization, well, simple. ... can use it as a lock (strictly speaking, a Hoare monitor). ...
    (comp.lang.java.programmer)
  • Re: Multithreaded file locking solution?
    ... No exceptions get thrown by the tryLock statement. ... What if it is a different Java process? ... If the lock is null, I continue to the next file. ... >> connections and have it assigns them round robin style to the parse ...
    (comp.lang.java.programmer)
  • Re: thread memory size
    ... internally contain locks, for example, they lock cache lines. ... even more concurrency within CAS operations than previous types of CAS ... contention one would normally get if one used lock based algorithms. ...
    (comp.os.linux.development.system)
  • Re: Thread Management
    ... You can synchronise on an object to enforce a critical section. ... It is a concern though that you're holding a lock during a wait. ... If load testing is what you're after, then you'd want other threads to ... For handing results to other threads, Java 1.4 provides a between-thread ...
    (comp.lang.java.programmer)
  • Re: SyncLock (Lock)
    ... sometime you may have finer grain locking going on. ... is nothing wrong with locking on your list object if that is the only lock ... | I come from a Java background and I'm familiar with monitors in java. ...
    (microsoft.public.dotnet.framework)