Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Mar 2003 19:30:59 +0100
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, Nate Lawson <nate@root.org>
Subject:   Re: cvs commit: src/sys/sys devicestat.h 
Message-ID:  <3039.1047321059@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 10 Mar 2003 13:26:17 EST." <XFMail.20030310132617.jhb@FreeBSD.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <XFMail.20030310132617.jhb@FreeBSD.org>, John Baldwin writes:
>
>On 10-Mar-2003 Poul-Henning Kamp wrote:
>> In message <Pine.BSF.4.21.0303101009420.93727-100000@root.org>, Nate Lawson wri
>> tes:
>> 
>> Doesn't work:
>> 
>>       CPU0 (kernel)           CPU1 (userland)
>> 
>>       increment seq
>>                               start copy
>>       fiddle data
>>                               end copy
>>                               (copy is inconsistent)
>> 
>> You need two sequence fields:
>> 
>>       CPU0 (kernel)           CPU1 (userland)
>> 
>>       increment seq0
>>                               start copy
>>       fiddle data
>>                               end copy
>>       increment seq1
>>                               (seq0 != seq1 indicates inconcistent data)
>> 
>> Notice that to make it absolutely water-tight, the seq fields must
>> be updated with appropriate write barriers and the order of the
>> fields must be the opposite as the direction the copy is performed in.
>
>Correct.  If you use:
>
>        atomic_add_acq_int(&seq0, 1);
>        ... all the updates ...
>        atomic_add_rel_int(&seq1, 1);
>
>then you should have sufficient membars.

Right, but even with that, I still need to make sure that the
userland copy starts out by copying seq1 and finishes by copying
seq0, and since that may depend on the mood of the compiler and the
phase of the moon.

This is disk statistics, it's not really worth that effort.  The
data in the structure will not get corrupted, bue one of our
readings may.  So what...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-src" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3039.1047321059>