Date: Fri, 18 Apr 2003 01:01:20 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <3E9FB0D0.57CF9343@mindspring.com> References: <Pine.GSO.4.10.10304180226040.5123-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:
> Ahh, OK. There aren't that many locks used by the library.
> We can probably come up with something that does what you
> want.
I don't think it's an issue (IMO -- see other post). However,
if you guys are really concerned with this (in the kernel, too,
if it comes to that), then add a "parent_lock" parameter to
the mutex creation routine, and set it.
Then, if you think there is an issue, you can instrument it
by simply checking that the lock is held by the same entity
all the way to the root, when you acquire a lock.
This beats the witness approach all to heck for diagnostics:
you can collect/check all the information you want about the
locking entities (thread id, process id, program counter at
which the lock was asserted, whatever).
Also, at some point, this structure would allow you to have
both intention mode locking ("SIX" locks), and allow you to
lock partial lists instead of complete lists, to reduce
overall contention (e.g. divide a list into 8 parts, one
lock per part, create another lock parent, assign it as the
parent of all 8 locks, and then get a SIX lock on the parent
when you are planning on traversing the list, and then rotor
through an X lock on all the inferior locks as you traverse
each range -- yields a concurrency of 8, with 1/8 the stall
length for write locks).
-- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9FB0D0.57CF9343>