cvs commit: src/sys/amd64/conf GENERIC

[Alfred Perlstein]

* Daniel Eischen <eischen at vigrid.com> [040614 13:09] wrote:
> On Mon, 14 Jun 2004, Alfred Perlstein wrote:
> 
> >  DbEnv::set_tas_spins
> > 
> >    Specify that test-and-set mutexes should spin tas_spins times without
> >    blocking. The value defaults to 1 on uniprocessor systems and to 50
> >    times the number of processors on multiprocessor systems.
> > 
> >    The database environment's test-and-set spin count may also be set
> >    using the environment's DB_CONFIG file. The syntax of the entry in
> >    that file is a single line with the string "set_tas_spins", one or
> >    more whitespace characters, and the number of spins. Because the
> >    DB_CONFIG file is read when the database environment is opened, it
> >    will silently overrule configuration done before that time.
> 
> I think you're missing his point.  Adaptive mutexes _do_ spin.
> The optimization is that they spin for only as long as the
> current owner is running (on another CPU).  If the owner is
> not running or stops running, the thread blocks.
> 
> The kernel knows about its threads, which thread owns a
> mutex, and whether that thread is running.  And since
> the desire is for mutexes to be held for short periods, it
> is better for the requesting thread to spin as long as the
> owning thread is running.  And conversely, it doesn't make
> sense to spin if the owning thread isn't running.

I understand what you're saying.  It's just that it seems that
we now have some subsystem locks where spinning as long as the
holder is running might be too long.

I said "might" I didn't say "will".

It might be interesting to put an upper bound on the amount of
spins.

Anyhow. :)

-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright at mu.org cell: 408-480-4684