DragonFly kernel List (threaded) for 2004-04
Re: lwkt_token progress
Yes. And I should add that the token abstraction isn't a license to
go nuts. The actual algorithm I am using is subject to greater and greater
levels of non-determinism as the number of tokens held increases. It's
important to separate the programming abstraction (which is trivial now)
from the reality (which is that you still want to be careful in what
and how many tokens you hold), but at least the problems can be fixed
in one place, the token implementation, rather then having to rip up
the entire codebase. I think that's very important. If FreeBSD-5 were
to change the fundamentals of the way they use mutexes, they would have
to rip their entire codebase to shreds. If I wanted to change, say,
the cpu-centric token ownership model to a mutex-like acquire-and-release
(that still follows our token semantics), I only have to change the
internals of the lwkt_gettoken() and lwkt_reltoken().
In regards to unexpected blocking situations.. well, when you use a token you have to expect that you might block there. You can never assume you
won't. The reality is that for most tokens you won't block for long,
but if it is critical that you not block in a particular section of code
then you have to use the other major programming abstraction in DragonFly,
which is the per-cpu globaldata mechanism and LWKT (light weight kernel
threading) mechanism. Many subsystems in DragonFly do not need tokens,
mutexes, or locks of any kind because they are built ground-up to be
MP friendly. For example, the LWKT scheduler does not require locks or
tokens of any sort, and it only messes with the Big Giant Lock on behalf
of the thread it is trying to switch to, not because it needs it itself
:On Thu, Apr 01, 2004 at 02:27:08PM +0100, Jan Grant wrote:
:> This seems like a very nice scheme. My initial gut feeling was that it
:> could potentially lower the error rate for coding against this scheme
:> compared, say, to the correct application of mutex+lock.
:It is a lot simpler. E.g. have a look at stage II of the kobj changes.
:We have a blocking condition for malloc (M_INTWAIT !), therefore we have
:to check against races. But and that's why this code is much simpler then
:e.g. FreeBSD kobj code, we have the guaranty that we have all tokens and
:critical sections back in place when the thread continues. We don't have
:to play the mutex dropping and retry game, just the race detection.
:> How common are "blocking conditions", though? It occurred to me that
:> the ease of using serialisation tokens might lead to their prevalence;
:> have you anything in mind to avoid the situation where a code path
:> suddenly potentially blocks due to a modification of some function it
:> (opaquely) depends upon due to a deep call graph?
:Well, you should always keep in mind that tokens don't guaranty atomicy
:over blocking conditions, since that's the reason why dead locks can't
:occur. You are normally doing something wrong if you hold a token, expect
:atomicy and call arbitrary deep functions.
:> By "something in mind" I mean some kind of guideline for best use of
:> these things.
:There are quite a few good examples already in the tree.
:> jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
:> Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
:> Usenet: The separation of content AND presentation - simultaneously.