Ok, I took a look at the libc and the kernel implementation of rwlocks.
I'm a little worried if I got this right, because most of the ZFS code can run
both in userspace and in the kernel, which seem to behave differently in the
RW_xxx_HELD() macros, and I need to port it correctly.
This is what
Ricardo Correia wrote:
> Ok, I took a look at the libc and the kernel implementation of rwlocks.
>
> I'm a little worried if I got this right, because most of the ZFS code can
> run
> both in userspace and in the kernel, which seem to behave differently in the
> RW_xxx_HELD() macros, and I nee
On Fri, Jun 02, 2006 at 05:50:21AM +0100, Ricardo Correia wrote:
> On Friday 02 June 2006 05:12, Neil Perrin wrote:
> > I believe RW_LOCK_HELD checks it's not held by the calling thread only.
> > Note, a thread should not doubly read lock the same lock as
> > a write lock from another thread betwee
On Friday 02 June 2006 05:12, Neil Perrin wrote:
> I believe RW_LOCK_HELD checks it's not held by the calling thread only.
> Note, a thread should not doubly read lock the same lock as
> a write lock from another thread between the 2 would deadlock.
Ok, that makes sense. Thanks :)
I'm assuming RW
Hi,
I think I found a bug in the rw_enter() implementation (emulation?) in
libzpool, file /usr/src/lib/libzpool/common/kernel.c:
void
rw_enter(krwlock_t *rwlp, krw_t rw)
{
ASSERT(!RW_LOCK_HELD(rwlp));
ASSERT(rwlp->rw_owner != (void *)-1UL);
ASSERT(rwlp->rw_owner != curthr
I believe RW_LOCK_HELD checks it's not held by the calling thread only.
Note, a thread should not doubly read lock the same lock as
a write lock from another thread between the 2 would deadlock.
Ricardo Correia wrote On 06/01/06 22:03,:
> Hi,
>
> I think I found a bug in the rw_enter() implementa
