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