On Fri, 10 Oct 2003, Tim Kientzle wrote:
TK>Harti Brandt wrote:
TK>> Yes. When I read the C standard
TK>>foo = data & mask;
TK>> wouldn't also help, because there is no sequence point in this statement
TK>> except at the ;.
TK>
TK>Before anyone takes this particular line of reasoning seriously
Bruce M Simpson wrote:
On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote:
On further inspection, I'm pretty sure that sys/kern/subr_devstat.c
is not correct.
OK. What about the shared page interface? Specifically the comment
above devstat_end_transaction().
I'm not entirely happy about
On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote:
> On further inspection, I'm pretty sure that sys/kern/subr_devstat.c
> is not correct.
OK. What about the shared page interface? Specifically the comment
above devstat_end_transaction(). The generation count is used by
the old sysctl i
Bruce M Simpson wrote:
Or keep a generation count to detect pre-emption (the devstat code does
this, amongst other things), and try again if you lost the race.
On further inspection, I'm pretty sure that sys/kern/subr_devstat.c
is not correct.
In particular, sysctl_devstat writes out a node's data
On Thu, Oct 09, 2003 at 07:24:15PM +0200, Bernd Walter wrote:
>> Note that, possibly contrary to expectations, 8-bit and 16-bit
>> _writes_ are not atomic on many (all?) the 64-bit architectures.
>> Small writes are generally done by doing a 64-bit read, insert
>> under mask and 64-bit write.
>
>Th
Bruce M Simpson wrote:
On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
You need to lock when reading if you insist on consistent data. Even a
simple read may be non-atomic (this should be the case for 64bit
operations on all our platforms).
Or keep a generation count to detect pre-emp
On Thu, Oct 09, 2003 at 12:46:44PM -0700, Jeffrey Hsu wrote:
+> This case (along with some other cases where locks of atomic reads
+> are required) is covered in the paper as
+>
+> But, one case where locks would be required is if the field
+> temporarily holds a value that no one else is supp
Terry Lambert wrote:
For certain uses, however, it's safe to not lock before the
read *on Intel architectures*. This can go out the window on
SPARC or PPC, or any architecture where there is no guarantee
that there won't be speculative execution or out-of-order
execution without explicit synchroni
Harti Brandt wrote:
Yes. When I read the C standard
foo = data & mask;
wouldn't also help, because there is no sequence point in this statement
except at the ;.
Before anyone takes this particular line of reasoning seriously,
I feel compelled to point out that sequence points have nothing t
On Thu, 9 Oct 2003, Jeffrey Hsu wrote:
JH> > I'm wondering...
JH> > Jeffrey Hsu was talking about this at BSDCon03.
JH> > There is no need to lock data when we just made simple read, for example:
JH> >
JH> > mtx_lock(&foo_mtx);
JH> > foo = 5;
JH> > mtx_unlock(&foo_mtx);
JH> > b
> I'm wondering...
> Jeffrey Hsu was talking about this at BSDCon03.
> There is no need to lock data when we just made simple read, for example:
>
> mtx_lock(&foo_mtx);
> foo = 5;
> mtx_unlock(&foo_mtx);
> but only:
> bar = foo;
>
> IMHO this is quite dangero
On Thu, Oct 09, 2003 at 07:37:42PM +1000, Peter Jeremy wrote:
> On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
> >You need to lock when reading if you insist on consistent data. Even a
> >simple read may be non-atomic (this should be the case for 64bit
> >operations on all our platfo
Frank Mayhar wrote:
> The other thing is that the unlocked reads about which I assume Jeffrey
> Hsu was speaking can only be used in very specific cases, where one has
> control over both the write and the read. If you have to handle unmodified
> third-party modules, you have no choice but to do l
On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
>You need to lock when reading if you insist on consistent data. Even a
>simple read may be non-atomic (this should be the case for 64bit
>operations on all our platforms). So you need to do
>
>mtx_lock(&foo_mtx);
>bar = foo;
>mtx_unlock
Harti Brandt wrote:
> You need to lock when reading if you insist on consistent data. Even a
> simple read may be non-atomic (this should be the case for 64bit
> operations on all our platforms). So you need to do
>
> mtx_lock(&foo_mtx);
> bar = foo;
> mtx_unlock(&foo_mtx);
>
> if foo is a dataty
I read the thread hoping to see a succint response to this and so far I don't
see it. Here goes...
Pawel Jakub Dawidek wrote:
> I'm wondering...
> Jeffrey Hsu was talking about this at BSDCon03.
> There is no need to lock data when we just made simple read, for example:
>
> mtx_lock(&foo_m
On Wed, Oct 08, 2003 at 02:58:02PM +0200, Harti Brandt wrote:
> uint8_t foo;
>
> (guaranteeing that the data type itself is atomic). But if a writer sets
> foo as above and you read foo without locking, you might get a wrong
> value:
>
> mtx_lock(...)
> foo = 77;
>
>
On Wed, 8 Oct 2003, Bernd Walter wrote:
BW>On Wed, Oct 08, 2003 at 02:11:12PM +0200, Harti Brandt wrote:
BW>> On Wed, 8 Oct 2003, Bernd Walter wrote:
BW>>
BW>> BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote:
BW>> BW>> But I'm not talking about non-atomic reads. What I'm wan
On Wed, Oct 08, 2003 at 02:11:12PM +0200, Harti Brandt wrote:
> On Wed, 8 Oct 2003, Bernd Walter wrote:
>
> BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote:
> BW>> But I'm not talking about non-atomic reads. What I'm want to show is that
> BW>> even atomic read (without lock
On Wed, 8 Oct 2003, Bernd Walter wrote:
BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote:
BW>> On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
BW>> +> You need to lock when reading if you insist on consistent data. Even a
BW>> +> simple read may be non-atomic (t
On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
> +> You need to lock when reading if you insist on consistent data. Even a
> +> simple read may be non-atomic (this should be the case for 64bit
> +> operations on a
On Wed, 8 Oct 2003, Bruce M Simpson wrote:
BMS>On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
BMS>> You need to lock when reading if you insist on consistent data. Even a
BMS>> simple read may be non-atomic (this should be the case for 64bit
BMS>> operations on all our platforms).
B
On Wed, 8 Oct 2003, Pawel Jakub Dawidek wrote:
PJD>On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
PJD>+> You need to lock when reading if you insist on consistent data. Even a
PJD>+> simple read may be non-atomic (this should be the case for 64bit
PJD>+> operations on all our platfo
On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote:
> But I'm not talking about non-atomic reads. What I'm want to show is that
> even atomic read (without lock) is dangerous in some cases.
>
> +> If you don't care about occasionally reading false data (for statistics or
> +> such
On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
> You need to lock when reading if you insist on consistent data. Even a
> simple read may be non-atomic (this should be the case for 64bit
> operations on all our platforms).
Or keep a generation count to detect pre-emption (the devsta
On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:
+> You need to lock when reading if you insist on consistent data. Even a
+> simple read may be non-atomic (this should be the case for 64bit
+> operations on all our platforms). So you need to do
+>
+> mtx_lock(&foo_mtx);
+> bar = foo;
On Wed, 8 Oct 2003, Pawel Jakub Dawidek wrote:
PJD>Hello hackers...
PJD>
PJD>I'm wondering...
PJD>Jeffrey Hsu was talking about this at BSDCon03.
PJD>There is no need to lock data when we just made simple read, for example:
PJD>
PJD>mtx_lock(&foo_mtx);
PJD>foo = 5;
PJD>mtx_unlock(&foo_
Hello hackers...
I'm wondering...
Jeffrey Hsu was talking about this at BSDCon03.
There is no need to lock data when we just made simple read, for example:
mtx_lock(&foo_mtx);
foo = 5;
mtx_unlock(&foo_mtx);
but only:
bar = foo;
IMHO this is quite dangerous.
Let's
28 matches
Mail list logo
