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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
