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
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 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/
_
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
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
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:
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
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
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:/
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
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 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 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 Friday 27 April 2007 02:43:16 am Marc Lörner wrote:
> On Thursday 26 April 2007 19:49, John Baldwin wrote:
> > On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote:
> > > Hello,
> > > I googled but found nothing about the usage of the kern_* functions
> > > (kern_open, kern_close, kern_pwrite
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
For core files and checkpoints that isn't possible.
-Kip
On 4/27/07, John Baldwin <[EMAIL PROTECTED]> wrote:
On Friday 27 April 2007 02:43:16 am Marc Lörner wrote:
> On Thursday 26 April 2007 19:49, John Baldwin wrote:
> > On Thursday 26 April 2007 08:08:19 am Marc Lörner wrote:
> > > Hello,
> >
>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
17 matches
Mail list logo
