On Saturday 21 May 2005 00:49, Peter Jeremy wrote:
> On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
> >Non-blocking mode has got to be supported. Else you get a nightmare
> > rewriting the code to support blocking mode.
>
> Your code either has to block somewhere or fail. contigmalloc() only
> blocks if it couldn't satisfy the request immediately. If it returns
> to your code, you still have the problem of needing the memory and
> not being able to allocate it without blocking.
That is not the problem. The problem is that it sleeps, which will exit the
Giant lock, which means another thread can change the state of what I am
about to setup meanwhile:
one_thread:
mtx_lock(&Giant);
if(sc->gone == 0)
{
sc->data = contigmalloc();
}
mtx_unlock(&Giant);
another_thread:
mtx_lock(&Giant);
if(sc->data)
{
contigfree();
sc->data = NULL;
}
sc->gone = 1;
mtx_unlock(&Giant);
The problem is that the undefined state: "sc->data != NULL" and
"sc->gone == 1" can be reached.
>
> >Can anyone explain why "uiomove()" has to sleep, and why there is no
> >non-blocking "uiomove()"?
>
> As far as I can see, uiomove() only sleeps if it is asked to do a
> kernel<->userland move that takes more than twice a scheduler quantum.
> As long as you don't uiomove() ridiculous amounts of data, it should
> never sleep.
>
On Saturday 21 May 2005 00:56, Don Lewis wrote:
>
> It can also sleep if it stumbles across a userland page that isn't
> resident. When this happens, it will sleep until the page is retrieved
> from swap.
The fact that uiomove(), copyout(), copyin(), contigmalloc() and
bus_dmamem_alloc() can all sleep, should be documented somewhere, so that
people are not surprised.
--HPS
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
