On Fri, 17 Feb 2012, Andriy Gapon wrote:
Since this issue has generated a sudden interest, I would like to use this opportunity to point my older proposal as well: http://lists.freebsd.org/pipermail/freebsd-arch/2011-August/011405.html
Sorry I didn't check this now, and I don't remember it from last year :-).
Essentially the algorithm is: 1. atomically (CAS) reserve a space in the message data buffer 2. output full message to the reserved space (no contention here)
This was essentially what it did in 2003, but with a reservation of only 1 byte since that seemed to be enough at the time. There is still non-atomicity for outputting to the reserved space, and contention in the unlikely event that there are enough callers to wrap the message buffer (the old code mentions a problem if there are the number of concurrent callers is >= the size of the message buffer, but I think the problem is a bit larger than that -- it only takes 2 concurrent callers, with one going very slowly while the other repeats calls that fills the message buffer. One going slowly can probably be easily arranged by single stepping it in a debugger). But these problems are rare. BTW, -current seems to have broken the checksum update for negative characters by removing one of the u_char casts. The char from the msgbuf is still cast to u_char, but the char in the int arg is now cast directly to u_int. All versions cast both terms u_int, but these casts are unimportant since the checksum is a u_int so the casts have no effect on systems with 32-bit 2's complement ints.
3. atomically (CAS) append a pointer to the message in the message pointers buffer
I wouldn't like this :-). Hmm, you could have a secondary buffer with hints to detect and recover from reordering in the main buffer. Bruce _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"