In article ,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>While working on getting the localcount(9) stuff whipped into shape, I
>ran across a situation where it is desirable to ensure that the current
>process/lwp does not already own a mutex.
>
>We cannot use !mutex_owned() since that doesn't return t
> Date: Sun, 30 Apr 2017 13:36:12 + (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> How frequently is this going to be used and what is the performance
> penalty for it. I am asking because I am running LOCKDEBUG all the time.
The idea is that it will be used unconditionally before po
On Sun, 30 Apr 2017, Taylor R Campbell wrote:
Date: Sun, 30 Apr 2017 13:36:12 + (UTC)
From: chris...@astron.com (Christos Zoulas)
How frequently is this going to be used and what is the performance
penalty for it. I am asking because I am running LOCKDEBUG all the time.
The idea is that i
On Sun, Apr 30, 2017 at 08:49:04AM +0800, Paul Goyette wrote:
> While working on getting the localcount(9) stuff whipped into shape, I ran
> across a situation where it is desirable to ensure that the current
> process/lwp does not already own a mutex.
>
> We cannot use !mutex_owned() since that d
On 01.05.2017 00:12, co...@sdf.org wrote:
> On Sun, Apr 30, 2017 at 08:49:04AM +0800, Paul Goyette wrote:
>> While working on getting the localcount(9) stuff whipped into shape, I ran
>> across a situation where it is desirable to ensure that the current
>> process/lwp does not already own a mutex.
On Sun, 30 Apr 2017, co...@sdf.org wrote:
I feel like we mostly care about adaptive mutexes, how about this
alternate suggestion?
mutex_adaptive_owned(kmutex_t * mtx)
{
if (mtx == NULL)
return 0;
KASSERT(MUTEX_ADAPTIVE_P(mtx));
return MUTEX_OWNER(mtx->mt
On Mon, 1 May 2017, Kamil Rytarowski wrote:
I find it weird to have two names which kinda mean the same thing but
also don't, and it's not immediate what the difference is, but not sure
if I can come up with better names.
I agree with this, it's very odd.. Can we just make this mutex_ownable(
On Mon, 1 May 2017, Paul Goyette wrote:
On Sun, 30 Apr 2017, Taylor R Campbell wrote:
Date: Sun, 30 Apr 2017 13:36:12 + (UTC)
From: chris...@astron.com (Christos Zoulas)
How frequently is this going to be used and what is the performance
penalty for it. I am asking because I am running LO
> Date: Sun, 30 Apr 2017 22:12:48 +
> From: co...@sdf.org
>
> I have an alternate proposal for the same purpose, but not much of a
> suggestion for yours.
>
> I find it weird to have two names which kinda mean the same thing but
> also don't, and it's not immediate what the difference is, but
> Date: Mon, 1 May 2017 04:58:52 +0800 (+08)
> From: Paul Goyette
>
> >> Date: Sun, 30 Apr 2017 13:36:12 + (UTC)
> >> From: chris...@astron.com (Christos Zoulas)
> >>
> >> How frequently is this going to be used and what is the performance
> >> penalty for it. I am asking because I am running
As for penalty, it should be very low. The expectation is that there
would be no contention for the lock, so no waiting for mutex_enter() to
finish. Just the cost of taking and releasing the mutex.
Actually, this can be a high penalty under contention when we could
have taken a no-lock fast pa
On Mon, May 01, 2017 at 07:39:55AM +0800, Paul Goyette wrote:
> > > As for penalty, it should be very low. The expectation is that there
> > > would be no contention for the lock, so no waiting for mutex_enter() to
> > > finish. Just the cost of taking and releasing the mutex.
> >
> > Actually,
On Sun, 30 Apr 2017, Chuck Silvers wrote:
Hence I suggest that mutex_ownable be limited to KDASSERT -- so that
you get it only if you combine DEBUG (expensive consistency checks)
and LOCKDEBUG (locking bug detection).
Yes, I agree. I've already made the KDASSERT() change in my local sources.
13 matches
Mail list logo
