Re: lwkt_token progress

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

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