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
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
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 mutex
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
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-calling to the
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
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
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 know it is
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 requirements
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 describe some of the
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
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
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
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
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
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 coding
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 one piece of
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
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 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 drivers, so
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 switch to
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--) {
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--)
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);
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 Giant
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
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_curr =
30 matches
Mail list logo
