Date: Sat, 18 Feb 2012 01:10:45 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andriy Gapon <avg@FreeBSD.org> Cc: marcel@FreeBSD.org, Eitan Adler <eadler@FreeBSD.org>, svn-src-all@FreeBSD.org, "Kenneth D. Merry" <ken@FreeBSD.org>, Marcel Moolenaar <marcel@xcllnt.net>, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@FreeBSD.org, Julian Elischer <julian@FreeBSD.org> Subject: Re: svn commit: r231814 - in head/sys: kern sys Message-ID: <20120218004042.L2893@besplex.bde.org> In-Reply-To: <4F3E2150.8030504@FreeBSD.org> References: <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org> <4F3CC40D.4000307@freebsd.org> <4F3CC5C4.7020501@FreeBSD.org> <4F3CC8A5.3030107@FreeBSD.org> <20120216174758.GA64180@nargothrond.kdm.org> <20120217053341.R1256@besplex.bde.org> <20120217000846.GA7641@nargothrond.kdm.org> <4F3D9D03.6020507@FreeBSD.org> <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> <4F3E2150.8030504@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120218004042.L2893>