From owner-freebsd-smp  Wed Sep  6 11: 5:31 2000
Delivered-To: freebsd-smp@freebsd.org
Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189])
	by hub.freebsd.org (Postfix) with SMTP id 8B54A37B422
	for <smp@freebsd.org>; Wed,  6 Sep 2000 11:05:20 -0700 (PDT)
Received: (qmail 17891 invoked from network); 6 Sep 2000 18:08:03 -0000
Received: from cx435051-d.fed1.sdca.home.com (HELO thirteen.flargh.com) (u6030@24.5.33.77)
  by tristero.cryptocourier.com with SMTP; 6 Sep 2000 18:08:03 -0000
To: smp@freebsd.org
Subject: Re: Sept 5th patch ... 
In-Reply-To: Your message of "Wed, 06 Sep 2000 19:37:51 +0200."
             <200009061737.e86Hbqd08340@grimreaper.grondar.za> 
Date: Wed, 06 Sep 2000 11:00:15 -0700
From: joel boutros <jdb@layer8.net>
Message-Id: <20000906180520.8B54A37B422@hub.freebsd.org>
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> So, are there going to be some documented guidelines for us neophyte
> kernel-hackers? I have just gotten used to the splfoo()/splx() idea,
> and now its gone. How, now, do we write canonical code that doesn't
> futz with itself when interrupts/threads/processes happen?

the general trick is locking critical sections of code or data.
previously when you did an splXXX(), you were assured that you
weren't going to get interrupted by anything of specified priority
or lower, so it was safe to assume your data probably wasn't going
to change out from under you.  now, you mark the critical sections
as in-use, and if something else does come in, it checks to see if
the section is "available" and, if not, figures out some strategy
to deal with it.

your critical section can be finely-grained (data such as members
of a structure or elements of a queue) or coarsely-grained (holding
an exclusive lock on an entire subsystem, like the network stack).
and your locks can appear in a number of varieties.  the strategy
employed depends on your implementation.

i'd recommend picking up a book on threads programming.  the real
gist of the change is that instead of telling the system you don't
want to be interrupted, you make your code more tolerant of
interruptions, which is what multithreading really requires.

- joel


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message