Re: race on multi-processor solaris
From: Jonathan Adams (jonathan-ggl_at_ofb.net)
Date: 11/28/03
- Next message: Jim Cochrane: "Re: Do you need an X server on an headless server to run X apps over ssh (X forwarding) ?"
- Previous message: Jonathan Adams: "Re: c-stack for the Java based process"
- In reply to: Joe Seigh: "Re: race on multi-processor solaris"
- Next in thread: Casper H.S. Dik: "Re: race on multi-processor solaris"
- Reply: Casper H.S. Dik: "Re: race on multi-processor solaris"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Next message: Jim Cochrane: "Re: Do you need an X server on an headless server to run X apps over ssh (X forwarding) ?"
- Previous message: Jonathan Adams: "Re: c-stack for the Java based process"
- In reply to: Joe Seigh: "Re: race on multi-processor solaris"
- Next in thread: Casper H.S. Dik: "Re: race on multi-processor solaris"
- Reply: Casper H.S. Dik: "Re: race on multi-processor solaris"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|