lkml.org 
[lkml]   [2008]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: file offset corruption on 32-bit machines?
From
On Fri, Apr 11, 2008 at 02:24:34PM +0200, Bodo Eggert wrote:
> AS far as I understand, the race is e.g.:
>
> fpos := A:a, we want to make process/thread a read A:b or B:a without it
> being a correct value in fpos. a!=b!=c, A!=B, A!=C.
>
> a: read fpos.high (A:?)
> b: write fpos (B:b)
> a: read fpos.low (A:b)
>
>
> If you change this to
>
> a: read fpos.high
> a: read fpos.low
> a: read fpos.high
> a: read fpos.low
>
> and compare the results, you need to
>
> a: read fpos.high (A:?)
> b: write fpos (B:b)
> a: read fpos.low (A:b)
> b: write fpos (A:c)
> a: read fpos.high (A:b),(A:?)
> b: write fpos (C:b)
> a: read fpos.low (A:b),(A:b)
>
> That would be winning three races in order to hit the bug.
>
>
> OTOH, writers MUST NOT be interrupted, because:
>
> b: write fpos.high (B:a)
> a: read fpos.high (B:?)
> a: read fpos.low (B:a)
> a: read fpos.high (B:a),(B:?)
> a: read fpos.low (B:a),(B:a)
> b: write fpos.low (B:b)

So if you write multithreaded code and don't understand what locking
around shared resources is for, then your application might break. Can
you give an example where locking is being used correctly where this can
possibly fail? The kernel can't prevent idiots from writing bad code
that breaks.

I just don't get this "problem".

--
Len Sorensen


\
 
 \ /
  Last update: 2008-04-11 15:59    [W:0.139 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site