Re: lwkt_token progress

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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
    (it doesn't).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

: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.
:
:Joerg
:
:> 
:> -- 
:> 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.
:>