Date: Mon, 11 Sep 2000 11:47:46 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Chuck Paterson <cp@bsdi.com> Cc: arch@freebsd.org Subject: Re: Interruptable mutex aquires. Message-ID: <20000911114746.G12231@fw.wintelcom.net> In-Reply-To: <200009111815.MAA21525@berserker.bsdi.com>; from cp@bsdi.com on Mon, Sep 11, 2000 at 12:15:35PM -0600 References: <200009111815.MAA21525@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Chuck Paterson <cp@bsdi.com> [000911 11:15] wrote:
> Alfred Perlstein wrote on: Sun, 10 Sep 2000 19:36:02 PDT
> }
> }There's a lot of code in the kernel that does this:
> }
> }while(lock != mine) {
> } error = tsleep(&lock, PRIBIO, "foo", PCATCH);
> } if (error)
> } return(error);
> }}
> }lock = mine;
> }
> }Ok, well the equivelant way to do this with mutexes would be
> }to add a new function 'mtx_enter_interruptable()' [*]
> }that attempts to aquire a mutex but if interrupted returns
> }an error suitable for aborting the operation.
>
> In the followng the lock which is acquired is
> often held for long periods, including while an IO is in
> progress, where as mutexs don't want to be held across
> an io.
can you have a look here:
http://people.freebsd.org/~alfred/mpsafe/mpsafestack.diff
I'm wondering if what I'm doing with socketbuffers is 'right'
basically the socketbuffer is still protected by a sleep+flags
loop, however the flags are actually protected by a mutex
on the socket itself and msleep is called after setting the
flags to request a wakeup with PCATCH set.
or from my journal at
http://people.freebsd.org/~alfred/mpsafe/stackjournal.txt :
Initially I wanted to place mutex locks in both the socket and
socketbuffer structures, that proved to be too painful, instead
use a lock on the socket and keep the old sleep/flags locking on
the socketbuffer, there isn't a race because the socketbuffer
flags are protected by my socket lock and the newly added msleep()
function allows me to maninpulate the flags and sleep on them
safely with my socket mutex interlocked.
It's a bit confusing to me because mutexes can be used for long
term mutual exclusion and one might still want to be able to
grab a signal and return an error if things go to pot.
thanks,
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000911114746.G12231>