Attilio Rao wrote:
Julian Elischer wrote:
Hans Petter Selasky wrote:
First of all: Where is FreeBSD's locking strategy document?
It is just started.. man 9 locking. it needs a lot of work still.
I'm working with rwatson@ about a document that can nicely fit in
locking(9), but we are a lit
Sergey Babkin wrote:
From: Julian Elischer <[EMAIL PROTECTED]>
Basically you shouldn't have a recursed mutex FULL STOP. We have a couple
of instances in the kernel where we allow a mutex to recurse, but they had to be
hard fought, and the general rule is "Don't". If you are recursing on
a mute
Julian Elischer wrote:
Hans Petter Selasky wrote:
First of all: Where is FreeBSD's locking strategy document?
It is just started.. man 9 locking. it needs a lot of work still.
I'm working with rwatson@ about a document that can nicely fit in
locking(9), but we are a little bit stuck in ter
Matthew Dillon wrote:
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated procedur
On Friday 27 April 2007 02:32:20 pm Hans Petter Selasky wrote:
> > > P0 unlock(1);
> > > P0 unlock(2);
> >
> > this looks "interesting".
> > Can you give a more concrete example of this?
> > what work is done in the upcall? WHo is upcalling to who?
>
> For example an USB device driver might be up-
On Fri, 27 Apr 2007, Julian Elischer wrote:
Basically you shouldn't have a recursed mutex FULL STOP. We have a couple of
instances in the kernel where we allow a mutex to recurse, but they had to
be hard fought, and the general rule is "Don't". If you are recursing on a
mutex you need to swit
On Thu, 26 Apr 2007, Julian Elischer wrote:
Further the idea that holding a mutex "except for when we sleep" is a
generally bright idea is also a bit odd to me.. If you hold a mutex and
release it during sleep you probably should invalidate all assumptions you
made during the period before you
>From: Julian Elischer <[EMAIL PROTECTED]>
>Basically you shouldn't have a recursed mutex FULL STOP. We have a couple
>of instances in the kernel where we allow a mutex to recurse, but they had to
>be
>hard fought, and the general rule is "Don't". If you are recursing on
>a mutex you need to sw
On Friday 27 April 2007 20:01, Julian Elischer wrote:
> Hans Petter Selasky wrote:
> > First of all: Where is FreeBSD's locking strategy document?
>
> It is just started..
> man 9 locking. it needs a lot of work still.
Excellent.
>
> > We should have a
> > global strategy when we write device dr
On Thursday 26 April 2007 03:36:33 pm Hans Petter Selasky wrote:
> Are there any comments on integrating this functionality into msleep(), and
> adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel?
Nope. Fix the code to not recurse instead, or to know it has a recursed mutex
On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
On Friday 27 April 2007 15:14, Daniel Eischen wrote:
When you hold a mutex, it should be for a very short time. And
I agree with the other comment that all drivers should be multi-thread
safe, so we shouldn't add cruft to allow for non MT-safe d
On Friday 27 April 2007 15:14, Daniel Eischen wrote:
> On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
> > On Thursday 26 April 2007 23:50, Attilio Rao wrote:
> >> 2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
> >>> The reason that mutexes ever recurse in the first place is usually
> >>> because
On Friday 27 April 2007 19:39, Matthew Dillon wrote:
> The real culprit here is passing held mutexes to unrelated procedures
> in the first place because those procedures might have to block, in
> order so those procedures can release and reacquire the mutex.
> That's just bad codin
Julian Elischer wrote:
I think trying to sleep with a recursed mutex should be an instant panic,
even if the mutex IS marked as being allowed to sleep.
I mean marked as being able to recurse.
___
freebsd-hackers@freebsd.org mailing list
http:/
Matthew Dillon wrote:
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated procedur
Hans Petter Selasky wrote:
First of all: Where is FreeBSD's locking strategy document?
It is just started..
man 9 locking. it needs a lot of work still.
We should have a
global strategy when we write device drivers, so that various modules can be
connected together without races and locki
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated procedure has no
clue as to
Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind manner.. in other word
On Fri, 27 Apr 2007, Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind
On 4/26/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote:
Hi,
In the new USB stack I have defined the following:
Could you perhaps describe some of the codepaths in the USB stack that
require this behavior?
--
Bosko Milekic <[EMAIL PROTECTED]>
http://www.crowdedweb.com/
_
Hans Petter Selasky wrote:
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
The reason that mutexes ever recurse in the first place is usually
because one piece of code calls itself (or a related piece of code) in a
blind manner.. in other word
Hans Petter Selasky wrote this message on Fri, Apr 27, 2007 at 07:50 +0200:
> On Thursday 26 April 2007 23:52, Bosko Milekic wrote:
> > On 4/26/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > In the new USB stack I have defined the following:
> >
> > Could you perhaps descr
On Thursday 26 April 2007 23:52, Bosko Milekic wrote:
> On 4/26/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > In the new USB stack I have defined the following:
>
> Could you perhaps describe some of the codepaths in the USB stack that
> require this behavior?
There are no req
On Thursday 26 April 2007 23:50, Attilio Rao wrote:
> 2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
> > The reason that mutexes ever recurse in the first place is usually
> > because one piece of code calls itself (or a related piece of code) in a
> > blind manner.. in other words, it doesn't kno
On Thursday 26 April 2007 23:18, Julian Elischer wrote:
> Hans Petter Selasky wrote:
> > Hi,
> >
> > In the new USB stack I have defined the following:
> >
> > u_int32_t
> > mtx_drop_recurse(struct mtx *mtx)
> > {
> > u_int32_t recurse_level = mtx->mtx_recurse;
> > u_int32_t recurse
2007/4/26, Julian Elischer <[EMAIL PROTECTED]>:
The reason that mutexes ever recurse in the first place is usually because one
piece of code calls itself (or a related piece of code) in a blind manner.. in
other
words, it doesn't know it is doing so. The whole concept of recursing mutexes
is a
In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: Are there any comments on integrating this functionality into msleep(), and
: adding mtx_drop_recurse() and mtx_pickup_recurse() to the FreeBSD kernel?
This is generally a bad idea. We allow it for Gian
2007/4/26, Hans Petter Selasky <[EMAIL PROTECTED]>:
Hi,
In the new USB stack I have defined the following:
u_int32_t
mtx_drop_recurse(struct mtx *mtx)
{
u_int32_t recurse_level = mtx->mtx_recurse;
u_int32_t recurse_curr = recurse_level;
mtx_assert(mtx, MA_OWNED);
w
Hans Petter Selasky wrote:
Hi,
In the new USB stack I have defined the following:
u_int32_t
mtx_drop_recurse(struct mtx *mtx)
{
u_int32_t recurse_level = mtx->mtx_recurse;
u_int32_t recurse_curr = recurse_level;
mtx_assert(mtx, MA_OWNED);
while(recurse_curr--)
29 matches
Mail list logo
