Fwd: Re: RFC: additions to the Glossary

[Chris Pepper]

>From: Ken Smith <kensmith at cse.Buffalo.EDU>
>To: George Keramidas <keramida at ceid.upatras.gr>
>Cc: Mark Linimon <linimon at lonesome.com>
>Cc: freebsd-doc at freebsd.org
>Subject: Re: RFC: additions to the Glossary

>On Tue, Jun 08, 2004 at 12:08:30PM +0300, George Keramidas wrote:
>  > On 2004-06-08 03:07, Mark Linimon <linimon at lonesome.com> wrote:

>  > An explanation of what "coarse" and "fine-grained" locking is, is
>>  probably going to be useful too.
>
>I don't know at what level to trim what follows, it's too long to put
>the whole thing in the entry.  But this is a bit of the history behind
>the need for this entry.  If any of it is useful cool...
>
>	As originally designed the UNIX kernel was not designed with
>	multiple processors per machine in mind.  If data structures
>	inside the kernel were accessed at the same time by code running
>	on two (or more) processors the data structures could become
>	corrupted (for example linked lists are notorious for this).
>	During the early stages of porting &os; to computers with
>	multiple processors the developers cheated.  It was set up
>	so that only one processor could possibly be executing code
>	inside the kernel at any point in time.  This was done by
>	creating a mutex named Giant, and any processor that needed
>	to enter the kernel needed to obtain the Giant mutex before
>	it could enter the kernel (and it had to release Giant when
>	done inside the kernel).  This allows user-level processes to
>	run on different processors at the same time but avoids the
>	need to "fix" the kernel's data structure issues all at once.
>	Once this method of operation (known as Asymmetric Multiprocessing
>	or Coarse-grained Multiprocessing) was working the Developers
>	started to work on allowing multiple processors to execute code
>	inside the kernel at the same time by creating mutexes that
>	protect individual data structures.  As time goes on more and
>	more sensitive data structures are protected by their own
>	mutexes.  More and more system calls (the main entry points
>	into the kernel) can now proceed without needing to obtain
>	the Giant mutex, and only stop if they need a mutex protecting
>	a specific data structure they require.  This is known as
>	Symmetric Multiprocessing or fine-grained Multiprocessing.  Work
>	is still progressing in certain areas of the kernel so there are
>	still cases where the Giant mutex is still required.

	I'd change "cheated" to "took a short cut" -- cheated implies 
that it wasn't a valid or reliable solution. Optimizing release 
timeframe at the cost of SMP efficiency was obviously considered 
appropriate when the decision was made, but this is no longer the 
case.


						Regards,


						Chris Pepper
--
Chris Pepper:               <http://www.reppep.com/~pepper/>
Rockefeller University:     <http://www.rockefeller.edu/>