svn commit: r231814 - in head/sys: kern sys

[Bruce Evans]

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