Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Aug 1997 16:03:19 -0600
From:      Steve Passe <smp@csn.net>
To:        Poul-Henning Kamp <phk@dk.tfs.com>
Cc:        smp@freebsd.org
Subject:   Re: HEADS UP: programming the SMP kernel 
Message-ID:  <199708082203.QAA00511@Ilsa.StevesCafe.com>
In-Reply-To: Your message of "Fri, 08 Aug 1997 16:27:41 %2B0200." <26062.871050461@critter.dk.tfs.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> 
> >We need to agree on the set of primatives available for coding SMP
> >specific kernel code.  Along with this we need a concise document describing
> >the dos and donts of SMP conforming code.
> 
> I think the right thing to do, is to stand firm on only the documentation
> part.
> 
> There are a multitude of locking primitives, and I don't think we should
> needlessly limit ourselves to one type, if there are better ones available
> for certain purposes.

I agree with this in the abstract.  But we need to introduce them in an orderly
way.  If we don't we will have endless grief trying to find deadlocks, etc.

Perhaps this is better expressed as:

We should start with the locks provided by the lite2 lock manager, and
add others as the need becomes obvious.  I am much more concerned with 
expanding to fine-grained locks in a manner that maintains kernel stability
than getting the greatest efficiency in the first pass.  Once we have gotten
to the point where we have pushed the locking down to the granularity we
want, we can then evaluate the locking types to see if alternatives make
sense.

If someone can point out glaring deficiencies in the lite2 lock manager
then this is a different matter...


---
> Certain operations can be done atomically (twiddle a bit in a word for
> instance) and I think we should leave the doors wide open for that kind
> of mechanisms too.

agreed, atomic data operations where then can be done are great, and I am
not suggesting that you do:

	push $_foolock
	call _simple_lock
	add $1, _foodata
	call _simple_unlock
	add $4, %esp
when:
	lock
	inc _foodata

will work.  This is a topic to the "how-to" document, describing
where each would be appropriate.


---
> The important thing is to get documented clearly what locking is used
> where, what hierarchies of objects&locks exists and some implementations
> of the locking primitives that will check this (#ifdef SMP_ANAL_RETENTIVE).

agreed.

--
Steve Passe	| powered by
smp@csn.net	|            Symmetric MultiProcessor FreeBSD





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708082203.QAA00511>