rmlock(9) two additions
Max Laier
max at love2party.net
Mon Aug 16 03:27:58 UTC 2010
Hi,
I'd like to run two additions to rmlock(9) by you:
1) See the attached patch. It adds rm_try_rlock() which avoids taking the
mutex if the lock is currently in a write episode. The only overhead to the
hot path is an additional argument and a return value for _rm_rlock*. If you
are worried about that, it can obviously be done in a separate code path, but
I reckon it not worth the code crunch. Finally, there is one additional
branch to check the "trylock" argument, but that's well past the hot path.
2) No code for this yet - testing the waters first. I'd like to add the
ability to replace the mutex for writer synchronization with a general lock -
especially to be able to use a sx(9) lock here.
The reason for #2 is the following use case in a debugging facility:
"reader":
if (rm_try_rlock()) {
grab_per_cpu_buffer();
fill_per_cpu_buffer();
rm_runlock();
}
"writer" - better exclusive access thread:
rm_wlock();
collect_buffers_and_copy_out_to_userspace();
rm_wunlock();
This is much cleaner and possibly cheaper than the various hand rolled
versions I've come across, that try to get the same synchronization with
atomic operations. If we could sleep with the wlock held, we can also avoid
copying the buffer contents, or swapping buffers.
Is there any concern about either of this? Any objection? Input?
Thanks,
Max Laier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rm_try_rlock.diff
Type: text/x-patch
Size: 5320 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20100816/e912dde2/rm_try_rlock.bin
More information about the freebsd-arch
mailing list