Date: Sun, 22 Sep 1996 08:13:46 -0700 (PDT) From: "Jonathan M. Bresler" <jmb> To: terry@lambert.org (Terry Lambert) Cc: terry@lambert.org, bad@owl.WPI.EDU, freebsd-smp@FreeBSD.org Subject: Re: multithreading in the kernel and applications. Message-ID: <199609221513.IAA03219@freefall.freebsd.org> In-Reply-To: <199609220951.CAA00353@phaeton.artisoft.com> from "Terry Lambert" at Sep 22, 96 02:51:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> A hierarchy with intention modes.
"intention modes". uh oh, another term i have never heard before.
what is an "intention mode" and how is one coded?
> IF you invoke a mutex without sharing which is an inferior node in
how can you have a "mutex without sharing"? if the data structure
that supports the mutex is not accessible to all processors, how
can it be used to acheive mutual exclusion? the mutual exclusion
primatives that i know rely on a datum that has at least two states:
locked and unlocked. each processor must read-modify-write the datum
in order to obtain the lock.
> a hierarchy of nodes, where some superior node is a mutext *with*
> sharing, THEN as long as the superior node has an intention mode
> established, the actual locking can be local to the inferior node.
superior node:
shared
uncached (or consistency protocol allows sharing)
contains structure (called intention mode), perhaps
many of these, each indicates a different purpose
for obtaining the lock in the superior node?
counted semaphore or multireader lock?????
inferior node:
shared
uncached (or consistency protocol allows sharing)
binary semaphore
SO, proc A can lock the superior node, set an "intention mode"
to write some files "A's file".
proc B comes along sees the superior node locked
and bumps the lock count then sets a different
"intention mode" which indicates it wants to write
"B's file" (use inode addresses for vnode addresses or
some unique thing as the "intention mode" data?????
or even the address of the inferior node. yeah thats better)
then you only have to obtain an exclusive lock on the inferior node???
> And thus local to a single processor and image of cache coherency...
> no additional bus arbitration need take place.
because coherency is enforced at the superior node??
since no one else is using my "intention mode"???
sounds interesting, but only for SOFTWARE MAINTAINED cache coherency
or systems that allow you to set the hardare coherency protocol on
a page by page basis. ala MIPS 4000, you set the superior node to
uncached and the inferior to noncoherent??
but if this is what you are talking about, it doesnt apply to the
intel processors does it? does intel support more than one
consistency protocol? could be, but i thought that it only
supported the MESI write-invalidate cache coherency protocol.
> In effect, you would establish a hierarchy of per-CPU "top level in
> the context of a single CPU" mutexes which could be used without
> forcing an update cycle. to the top level ("system wide") mutex.
you are talking software cache coherency, no?
intel gives us hardware cache coherency. why do we want
to incur the penalties of software cache coherency:
user shared memory cant be cached (this breaks the
programming paradigm which relies upon the operating
system to serialize access to memory, files,
etc--this is the essence of the problem with file
i/o and mmap calls),
spin locks can never be cached (so each processor
has to hammer the bus while trying to obtain a spin
lock, rather than just hammering its own cache),
process data must be flushed when a process migrates
from one processor to another (more bus transactions,
rather than letting the other processor take the
cache lines are needed).
even if we can arrange to cache some of this list, we must flush
that section of the cache before releasing the lock.
given the processor speed that we are using and the bus
speeds that we are limited to, memory and i/o bandwidth
seems to be very scarce, something that we must husband,
least the system spin like a whirling derivsh trying to
obtain the required locks to perform some real work ;(
terry, help me out here. i dont understand what you are saying.
jmb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609221513.IAA03219>