svn commit: r231814 - in head/sys: kern sys
Bruce Evans
brde at optusnet.com.au
Fri Feb 17 14:10:49 UTC 2012
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
More information about the svn-src-all
mailing list